研究所の基本は「公式API → MCP → ブラウザ」の順に確認。
公式APIで安定して取れるなら、まずAPI。複数のAIクライアントから同じ道具や資料を使わせたいならMCP。 APIがなく、画面上でしかできない操作に限ってブラウザ操作を選ぶ。ただし公開・送信・購入・削除はどの方法でも人間の確認を残します。
AIエージェントは担当者、APIとMCPは使う道具。
生成AIが「質問に答える人」だとすれば、AIエージェントは「ゴールを受け取り、必要な道具を選び、途中結果を見ながら仕事を進める担当者」です。 その担当者が外部サービスとつながる代表的な入口がAPIとMCPです。
ここで混同しやすいのは、AIエージェント、API、MCPを同じ種類の技術として比べてしまうことです。 AIエージェントは仕事を進める主体で、APIとMCPはその主体が外部へ手を伸ばすための接続方法です。
たとえば「今月発売される漫画を一覧にする」という仕事なら、エージェントが手順を考え、APIから書誌データを取得し、結果をカード用に整形します。 同じ取得機能を複数のAIから使いたい場合は、そのAPI処理をMCPツールとして渡す構成が考えられます。
何をするか考える
渡されたゴールを小さな手順に分け、許可された道具から必要なものを選びます。途中結果を読み、足りない情報があれば検索や再取得を行うのが、通常のチャットとの大きな違いです。
例：新刊漫画を集め、カードを作り、公開前に確認を頼むサービスへ直接注文する
開発者が接続先、送る項目、受け取るデータをあらかじめ決めます。同じ条件で何度も呼び出せるため、発売日や価格などの構造化データを安定して扱う仕事に向きます。
例：楽天ブックスから漫画の発売日と価格を取得AIが使える道具として渡す
ツール名、用途、入力項目などをAIが理解できる共通形式で提示します。AIは会話の目的に合わせて道具を選べますが、実際の通信では裏側のAPIを利用する場合もあります。
例：Notionの記事台帳を検索し、調査ログを追加3つは競合ではなく、接続する層が違う。
APIは、プログラム同士が決められた形式でリクエストとレスポンスを交換する入口です。 MCPは、AIアプリケーションが外部のツール・資料・定型プロンプトを発見し、利用するための共通プロトコルです。 ブラウザ操作は、人が見る画面そのものをクリック・入力して進めます。
APIでは、どの処理を呼ぶかをプログラム側が先に決めます。一方、MCPでは利用可能な道具の一覧をAIへ見せ、会話の文脈に応じて選ばせられます。 ブラウザ操作は、APIもMCPツールも用意されていない画面を動かす手段ですが、表示変更の影響を受けやすいため、研究所では最後に検討します。
構造化データ、速度、再現性を優先したい仕事
サービスごとの認証・仕様変更・エラー処理が必要
ツールや資料を、対応するAIクライアントから再利用したい仕事
ホスト側の対応状況、権限、接続方式の確認が必要
APIがない管理画面や、人が画面を見て行う手順
画面変更、ログイン、ポップアップの影響を受けやすい
APIとMCPは、接続する層が違う
同じ「つなぐ」でも、誰に何を見せる仕組みかが異なります。
向く仕事 同じデータ取得や更新を、正確に繰り返す
向く仕事 会話の途中で、AIに複数の道具を選ばせる
APIはサービスとの通信方法、MCPはAIへ道具を見せる方法です。既存APIを呼ぶ処理をMCPツールとして提供する構成もできます。
MCPの裏側で、公式APIを呼べる
二者択一ではなく、役割の違う層を重ねる構成です。
まず見るのは「その作業に公式APIがあるか」。
APIは、毎回同じ形でデータを取り、結果を次の処理へ渡す仕事に強い方法です。 記事制作と小さな事業運営で使いやすい例を並べます。
APIで先に決めるのは、「何を送り、何を受け取るか」。
APIを使うときは、まず公式ドキュメントで利用できる処理を確認します。たとえば書籍検索なら、キーワード、出版社、発売日、並び順などを送ると、タイトル、著者、価格、ISBN、商品URLなどが決められた形式で返ってきます。画面から文章を読み取るよりも、必要な項目を直接受け取れるため、データの整理や再利用がしやすくなります。
一方で、APIがあるだけで自動化が完成するわけではありません。認証情報の保管、呼び出し回数の制限、エラー時の再試行、仕様変更への対応が必要です。取得したデータにも間違いや欠落があり得るため、公開前に確認する項目を最初から決めておくことが重要です。
OpenAI
Responses API生成・構造化・ツール実行
生成・動画・表
GitHub
REST APIRelease・Issue・PR
Notion
Notion API記事台帳・文書
Shopify
Admin GraphQL API商品・在庫・注文
Stripe
Stripe API決済・請求・顧客
Rakuten
Books / Kobo API書籍・漫画・商品
Slack
Web API会話・通知
OpenAI Responses API
POST /v1/responses- 任せられる仕事
- 調査メモの構造化、比較表の作成、記事の初稿、ツール呼び出し。
- 向いている場面
- 入力と出力形式を決め、同じ手順を大量に繰り返すとき。
- 人間の確認
- 出力の事実確認と公開判断は人間側。
YouTube Data API
search.list / videos.list- 任せられる仕事
- 関連動画、チャンネル、公開日、再生数、説明文、サムネイルURLの取得。
- 向いている場面
- AI動画ツールの口コミ調査や、競合チャンネルの定点観測。
- 人間の確認
- クォータと著作権に注意。動画内容はメタデータだけで断定しない。
Notion API
POST /v1/search / pages / data sources- 任せられる仕事
- 記事台帳の検索、ページ作成、ステータス更新、構造化されたデータの同期。
- 向いている場面
- バッチ処理やサーバー側の定時実行など、完全自動に寄せたいとき。
- 人間の確認
- 接続先と共有したページだけを対象にする。
GitHub REST API
repos / issues / pulls / releases- 任せられる仕事
- 公式リリース、Issue、Pull Request、更新日の取得と変更差分の収集。
- 向いている場面
- OSSのAIツールやMCPサーバーの更新記事を作るとき。
- 人間の確認
- Issueの投稿やPRコメントは自動送信しない。
Shopify Admin GraphQL API
products / orders / inventory- 任せられる仕事
- 商品・バリアント・価格・在庫・注文情報を構造化して取得。
- 向いている場面
- 商品台帳とストアの差分確認、在庫アラート、商品説明の下書き。
- 人間の確認
- 価格・公開状態・在庫・返金は人間の承認後に書き込む。
Google Sheets API
values.get / update / append- 任せられる仕事
- 指定範囲の読み取り、調査結果の追記、記事・商品・検証台帳の同期。
- 向いている場面
- 人が同じ表も確認しながら、定型データだけを積み上げたいとき。
- 人間の確認
- 書き込み範囲をA1記法で固定し、上書き後は対象セルを再取得して照合する。
Gmail API
messages / labels / drafts- 任せられる仕事
- 受信メールの検索・分類・ラベル付け、返信案の下書き作成。
- 向いている場面
- 問い合わせの一次整理や、返信が必要なメールだけを抽出するとき。
- 人間の確認
- drafts.createとsendを分離し、宛先・本文・添付を人間が確認して送る。
Slack Web API
conversations.history / chat.postMessage- 任せられる仕事
- 参加中チャンネルの履歴取得、週報素材の抽出、確認済み通知の投稿。
- 向いている場面
- 会話ログから決定事項を拾い、NotionやSheetsへ整理するとき。
- 人間の確認
- 最初は履歴取得だけにし、chat:writeと投稿処理は別の承認工程にする。
楽天ブックス書籍検索API
BooksBook/Search/20170404- 任せられる仕事
- 漫画のタイトル、著者、発売日、価格、ISBN、表紙画像、在庫、商品URLの取得。
- 向いている場面
- 新刊漫画の一覧、作者別ページ、紙版の価格・在庫カードを作るとき。
- 人間の確認
- App IDとaccess keyはサーバー側で管理。楽天のクレジット表示とアフィリエイト表示を確認する。
楽天Kobo電子書籍検索API
Kobo/EbookSearch/20170426- 任せられる仕事
- 電子書籍のタイトル、著者、シリーズ、価格、表紙、商品URLの取得。
- 向いている場面
- 同じ漫画の紙版と電子版を分け、読者が選べるページを作るとき。
- 人間の確認
- 紙版APIと同じデータだと思い込まず、作品名・巻数・商品番号を別々に照合する。
MCPは「AIから使う道具箱」を接続する。
既存のAPIや業務処理を、AIクライアントが理解できる道具として提供できるのがMCPです。 同じ接続先をCodex、Cursor、その他の対応クライアントから再利用したいときに効きます。
MCPを使う価値は、AIが道具の意味を理解できること。
通常のAPI連携では、どのAPIをどの順番で呼ぶかをアプリ側のコードに書きます。MCPでは、「記事台帳を検索する」「指定したページへ調査結果を追記する」といった仕事の単位でツールを用意し、名前、説明、入力項目をAIへ伝えます。AIは利用できる道具を確認し、依頼内容に合うものを会話の途中で選べます。
ただし、MCPに接続しただけで安全になるわけではありません。検索だけのツールなのか、書き込みや削除までできるのかを分け、最初は必要最小限の権限から始めます。また、公式提供かコミュニティ提供か、誰が保守しているか、どの情報が外部へ送られるかも接続前に確認します。
Notion MCP
- 任せられる仕事
- ワークスペース横断検索、ページの読み書き、タスク更新。
- 選ぶ理由
- CodexやCursorなど複数のAIから、同じ記事台帳を使わせたいとき。
- 注意
- 公式のリモートMCPはユーザーOAuthで接続。無人バッチは、API認証と必要権限を別途設計する。
GitHub MCP Server
- 任せられる仕事
- コード、Issue、PR、Actions、リリースの調査と操作。
- 選ぶ理由
- 「このリポジトリの最新変更と未解決Issueから記事案を作る」といった会話型作業。
- 注意
- read-onlyモードで開始。投稿・マージ・ワークフロー実行は別承認にする。
Cloudflare MCP Servers
- 任せられる仕事
- DNS、Workers、ログ、観測、Browser Run、AI Gatewayなどの検索・診断・操作。
- 選ぶ理由
- 複数のCloudflare機能をAIから横断し、ログと設定を一緒に調べたいとき。
- 注意
- OAuthと権限選択が前提。設定変更より先に読み取りと提案だけを任せる。
Chrome DevTools MCP
- 任せられる仕事
- Chromeのページ遷移、クリック、入力、スクリーンショット、Console、Network、Performanceの確認。
- 選ぶ理由
- 実際の表示を見ながらサイトQAや管理画面の定型操作をさせたいとき。
- 注意
- Webページ側の指示を信用しすぎない。許可URL、専用プロファイル、外部操作前承認を設ける。
Higgsfield MCP
- 任せられる仕事
- AIエージェントから画像・動画・音声生成、生成履歴、各種メディアツールを扱う。
- 選ぶ理由
- チャット上で構成・プロンプト・参照素材・生成までをつなぎ、動画制作の往復を減らしたいとき。
- 注意
- MCP経由の生成はクレジットを消費する。実行前にモデル、尺、解像度、枚数と消費量を確認する。
サーバー名だけでなく、提供者、リポジトリ、権限、読み取り専用モードの有無を接続台帳に残します。
指示から動画を作るところまで、実際に試した。
白色寄りの部屋から暖色照明へ変化させる縦型動画です。開始画像と終了画像を参照にし、 Higgsfield CLI経由のSeedance 2.0 Image-to-Videoで生成しました。現在はHiggsfield公式MCPからも、 AIエージェントが動画生成機能へ接続できます。
- 実ファイル
- 5.042秒 / 1080×1920 / 24fps / 無音
- 固定したもの
- 壁、窓、カーテン、ベッド、ランプの数と位置
- 人間の確認
- モデル、参照画像、生成設定、クレジット、再生結果
ブラウザ操作は「どこのChromeを動かすか」まで決める。
Chrome DevTools MCPは、ChromeをAIから操作・検査する入口です。 そのChromeは手元のPCでも、CDPに対応したクラウドブラウザでも構いません。ここを混ぜると運用が不安定になります。
ブラウザ操作が必要なのは、画面にしか入口がないとき。
管理画面の表示確認、プレビューのスクリーンショット、フォーム入力など、公式APIでは扱えない作業があります。こうした仕事では、人が操作するのと同じ画面をAIに開かせ、クリックや入力を行わせます。ログイン済みのローカルChromeなら、自分が普段使っているサービスをそのまま確認しやすいのが利点です。
ただし、ボタンの位置や文言が変わると手順が止まりやすく、ポップアップや二段階認証の影響も受けます。定時監視などをクラウドで行う場合は、セッションの保管場所、料金、タイムアウトも考える必要があります。そのため、同じ情報をAPIで取得できるなら、研究所ではAPIを優先します。
ログイン済み画面を確かめるなら手元のChrome。公開ページを定時取得するならクラウド。便利さより先に、置き場所と権限を決めます。
ローカルChrome
既存ログインが必要な1回性の作業契約中SaaSの管理画面確認、プレビュー、スクリーンショット、Consoleエラー調査。
PCとChromeを起動しておく必要があり、ポップアップや画面変更に弱い。ローカルHeadless
開発・テスト用の再現可能な操作Playwright / Puppeteerでフォーム、リンク、レスポンシブ表示、スクリーンショットを検証。
個人のChromeセッションとは分ける。ログイン状態の管理が必要。クラウドブラウザ
定時実行・大量取得・サーバーからの無人実行Cloudflare Browser Renderingなどで公開ページを開き、Markdown化、画像取得、CDP / Playwright操作。
料金、セッション、タイムアウト、Bot対策の影響を受ける。個人の管理画面は安易に移さない。公開ページの定時取得はクラウド。自分のログインが必要な画面はローカルChrome。商品公開やメッセージ送信はどちらでも人間確認。
接続方法より先に、仕事を4つに分ける。
「何を使うか」ではなく、「何を任せたいか」から考える。
最初からMCPやブラウザ操作を導入しようとすると、必要以上に複雑になりがちです。まず任せたい仕事を一文で書き、その仕事の入力、処理、出力を分けます。「公開中の料金を読む」と「料金を変更する」では必要な権限がまったく違うため、同じ自動化としてまとめない方が安全です。
次に、同じ処理を繰り返すのか、状況に応じてAIに道具を選ばせたいのかを確認します。前者ならAPI、後者ならMCPが候補です。画面でしかできない作業だけをブラウザ操作へ回し、最後に人間が判断する場所を決めると、構成を必要以上に大きくせずに済みます。
読むだけか取得・検索だけなら、書き込み権限を渡さない。
同じ処理を繰り返すか入力と出力が決まっているほどAPI向き。
複数のAIから使うか共通の道具として配りたいならMCPを検討する。
最後に人間の判断が必要か公開・送信・購入・削除は確認点を先に決める。
接続方法は、仕事の形から選ぶ
研究所の基本的な検討順。絶対的な優劣ではありません。
記事、漫画サイト、EC運営。仕事にすると違いが見える。
接続方法の名前ではなく、入力・処理・出力・人間確認の4点で実務フローを組み立てます。
実務では、API・MCP・ブラウザを1つに統一しない。
ひとつの仕事でも、工程ごとに向いている接続方法は異なります。記事制作なら、動画やリリース情報の一覧取得はAPI、過去記事や編集方針の検索はMCP、完成したページの見た目確認はブラウザ操作という組み合わせになります。どれか一つですべてを処理しようとすると、壊れやすさや権限が増えてしまいます。
大切なのは、各工程の結果を次の工程へ渡せる形にすることです。取得した情報には出典URLと確認日を付け、AIが作った文章は下書きとして保存し、公開前の状態で止めます。こうして工程を分けると、失敗した場所を特定しやすく、人間が確認すべき範囲も明確になります。
公開情報を集め、根拠と未確認事項を分け、初稿までAIへ。最後の主張・広告表示・公開判断だけを編集者が持ちます。
- APIYouTube Data API
ツール名で検索し、公開日・チャンネル・再生数・動画URLを取得。
- APIGitHub REST API
OSSなら最新Release、更新日、主要Issueを取得し、公式変更の根拠にする。
- CLOUDクラウドブラウザ
公開中の料金・ヘルプ・更新履歴ページを開き、本文とスクリーンショットを保存。
- MCPNotion MCP
編集ポリシーと過去記事を検索し、調査ログを記事台帳に追加。
- APIOpenAI Responses API
出典URL、確定事実、未確認事項を分けた構造化初稿を作成。
- CHROMEChrome DevTools MCP
記事プレビューをスマホ幅で開き、リンク、画像、Console、Networkを検証。
- HUMAN編集者が公開判断
主張、出典、スクリーンショット、広告表示、リンク先を確認してから公開。
楽天の公式APIから、最速コミックカレンダー「コミカレ」を作った。
コミカレは、漫画の新刊をすばやく探せる、私が制作・運営している実在サービスです。紙の漫画を楽天ブックス書籍検索API、電子版を楽天Kobo電子書籍検索APIから別々に取得しています。
実際のコミカレを見る
公式APIから取得するのは作品の感想ではなく、タイトル、著者、発売日、価格、ISBN、表紙URL、商品URLなどの構造化データです。
size=9でコミックへ絞り、発売日の新しい順に12件取得。
タイトル、著者、発売日、価格、ISBN、表紙、リンクだけをカード用JSONへ。
スマホで表紙・巻数・発売日を確認しやすい一覧へ。品切れは除外。
作品名、巻数、価格、広告表示、遷移先を人間が確認して公開。
const params = new URLSearchParams({
applicationId: process.env.RAKUTEN_APP_ID,
affiliateId: process.env.RAKUTEN_AFFILIATE_ID,
formatVersion: "2",
size: "9", // Comic
availability: "1", // 在庫あり
sort: "-releaseDate", // 発売日の新しい順
hits: "12",
elements: [
"title", "author", "salesDate", "itemPrice",
"largeImageUrl", "affiliateUrl", "isbn"
].join(","),
});
const response = await fetch(
"https://openapi.rakuten.co.jp/services/api/BooksBook/Search/20170404?" + params,
{ headers: { accessKey: process.env.RAKUTEN_ACCESS_KEY } }
);
const payload = await response.json();
const items = payload.Items ?? payload.items ?? [];楽天Web Serviceでアプリを登録し、App IDとaccess keyを発行。アフィリエイトURLが必要ならaffiliateIdも指定します。サイト上では楽天のクレジット表示ガイドと、広告であることの明瞭な表示を確認します。
商品の取得はAPI、見た目の確認はChrome、公開は人間。
Admin GraphQL APIで商品・価格・在庫を読み取り、AIが説明文と改善案を作る。変更候補はNotion MCPで台帳化し、Chromeでストア表示を確認。価格更新と公開ボタンだけは人間が実行する。
「できる」操作と「勝手に進めてよい」操作は別。
MCPの仕様でも、ツールは外部操作やコード実行につながり得るため、利用者の同意と制御が重要とされています。 研究所では、公開・メッセージ送信・購入・削除・権限変更を自動完了させず、人間の確認を残します。
権限は、読む・下書き・反映・公開の順に広げる。
最初の検証では、検索や取得だけを許可します。結果が安定したら下書き作成へ進み、その次に限定した範囲への書き込みを試します。公開や送信まで一度に許可しないことで、誤った情報や意図しない操作がそのまま外部へ出るのを防ぎやすくなります。
人間の確認は、自動化の失敗ではありません。宛先、金額、公開範囲、削除対象など、後から戻しにくい判断を人が受け持つための工程です。AIには差分と判断材料をまとめさせ、人は最終判断に集中する、という分担が現実的です。
自動化は、権限を一段ずつ上げる
最初から公開権限まで渡さず、読む→下書き→限定反映の順で検証します。
この記事自体も、AIへ押し付けて作りました。
公式資料の候補収集、構成、初稿、サイトへの組み込みをAIへ依頼。テーマ選定、主張の境界、出典、公開判断は人間側に残しています。 ここからは試作で終わらせず、日次の実作業、費用、失敗、修正、人間の確認時間を追記していきます。
次は、やりたい仕事から道具を探す。
公式API・MCPを、用途、提供元、読み書き権限、認証方法で検索できます。具体的な使い方と最初の一手も掲載しています。
Sources
- Model Context Protocol — Specification 2026-07-28
- OpenAI Responses API — Create a response
- YouTube Data API — API Reference
- Notion API — Introduction
- GitHub REST API — Issues
- Shopify Admin GraphQL API — Products
- Gmail API — REST Reference
- Google Sheets API — Read & write cell values
- Slack Web API — conversations.history
- Slack Web API — chat.postMessage
- Notion MCP — Overview
- GitHub MCP Server — Official repository
- Cloudflare — Managed MCP servers
- Chrome DevTools MCP — Tool reference
- Cloudflare Browser Rendering — CDP and MCP support
- 楽天ブックス書籍検索API — 公式ドキュメント
- 楽天Kobo電子書籍検索API — 公式ドキュメント
- Rakuten Web Service — Usage Guide
- 消費者庁 — ステルスマーケティングに関するQ&A
- Higgsfield MCP — Official overview
- Higgsfield — MCPとWeb版の違い
- 実制作サービス — 最速コミックカレンダー