https://tinyaistudio.xyz OpenAI、Anthropic、Google、Hugging Face、MCP などの一次情報を、日本の開発者・PM・創業者向けに読解する編集サイト。 https://tinyaistudio.xyz/articles/zero-data-retention-retention-inventory/ https://tinyaistudio.xyz/articles/zero-data-retention-retention-inventory/ Sun, 21 Jun 2026 00:00:00 GMT このガイドが重要なのは、AI に入れたデータが全部同じ理由で残るわけではないと分けている点だ。 実際には、不正利用を見張るための短期ログ、会話やジョブを動かすための状態保存、外部接続先での保持が分かれている。 Zero Data Retention はその一部を減らす仕組みであって、全部の保存経路を消す魔法ではない。 だから日本の導入現場で必要なのは、『保存ゼロ』と言い切ることではなく、endpoint と tool ごとの retention 棚卸しである。 https://tinyaistudio.xyz/articles/enterprise-managed-authorization-org-access/ https://tinyaistudio.xyz/articles/enterprise-managed-authorization-org-access/ Sun, 21 Jun 2026 00:00:00 GMT この発表の本質は、MCP 接続を社員一人ひとりの手作業に任せるのをやめ、会社の権限ルールでまとめて配れるようにした点だ。 社員ごとに一つずつ接続させる方式は、最初は楽でも、入社・異動・退職や監査の場面で『誰が何につながっているか』を追いにくくする。 Enterprise-Managed Authorization は、その問題を個別の同意画面ではなく会社の認証基盤側で解く拡張として stable になった。 便利さより重要なのは、MCP 接続管理を個人作業から組織統制へ移せることだ。 https://tinyaistudio.xyz/articles/code-agent-vs-toolcalling-boundary/ https://tinyaistudio.xyz/articles/code-agent-vs-toolcalling-boundary/ Sun, 21 Jun 2026 00:00:00 GMT この guide の一番大事な点は、agent を一種類の便利機能として扱わず、『決められた道具を呼ぶ型』と『途中でコードまで書いて走らせる型』を分けていることだ。 この違いは賢さの話ではない。失敗のしかた、安全対策、監査のしやすさが変わる。 コードを書かせる型は複雑な問題を柔軟に解けるが、そのぶん実行環境を閉じ込める責任が重くなる。 逆に、決めた道具だけを決めた形で呼ぶ型は表現力は狭いものの、予測しやすく壊し方も限定しやすい。 https://tinyaistudio.xyz/articles/claude-code-settings-secret-read-boundary/ https://tinyaistudio.xyz/articles/claude-code-settings-secret-read-boundary/ Sat, 20 Jun 2026 00:00:00 GMT この docs の本当の論点は、秘密ファイルを『見つけにくくする』ことと『実際に読めなくする』ことは別だと切り分けた点にある。 AI coding agent では、検索結果から隠しても別経路で読めるなら保護にならない。だから非表示より強い『読み取り拒否』が必要になる。 Claude Code は旧 `ignorePatterns` から `permissions.deny` へ重心を移し、`Read(./.env)` のような読み取り自体を拒否する設計を前面に出した。 つまり settings の紹介というより、ローカル秘密をどの層で機械的に読ませないかという情報境界の文書として読むべきだ。 https://tinyaistudio.xyz/articles/define-your-agent-versioned-config/ https://tinyaistudio.xyz/articles/define-your-agent-versioned-config/ Sat, 20 Jun 2026 00:00:00 GMT このページの本当の論点は、agent をその場の長文指示として扱うのをやめ、何度でも同じ形で使える設定として持てるようにしたことだ。 毎回チャットに似た説明を書き直す運用では、担当者ごとに少しずつ違う agent が増え、何が効いたかも何を変えたかも追いにくくなる。 公式は、使う model、system、tools、MCP servers、skills などをまとめた agent 定義を保存し、更新ごとに版を増やす構造を示している。 つまり managed agent の読みどころは人格づけではなく、再利用、比較、改版ができる実行設定を資産として持てるかどうかだ。 https://tinyaistudio.xyz/articles/define-outcomes-rubric-grader-loop/ https://tinyaistudio.xyz/articles/define-outcomes-rubric-grader-loop/ Sat, 20 Jun 2026 00:00:00 GMT このページで重要なのは、AI に『終わった』と言わせるだけでは仕事完了の証明にならないと明示している点だ。 問題は二つある。AI は足りないまま完成と思いがちで、人間側も担当者ごとに採点基準がぶれやすい。 公式はそのズレを減らすために、何を満たせば合格かを書いた rubric と、別の判定役である grader による見直しループを用意している。 つまり本体は新しい機能名ではなく、完成条件を会話の外に出し、未達なら機械的に差し戻せるようにする設計だ。 https://tinyaistudio.xyz/articles/mcp-security-authorization-boundary/ https://tinyaistudio.xyz/articles/mcp-security-authorization-boundary/ Fri, 19 Jun 2026 00:00:00 GMT remote MCP で先に怖いのは、便利につなぐことではなく、ある client のために取った承認結果や token が別の client や別の server に流れることだ。 この docs は、その事故を抽象論で済ませず、同意の結び付け、戻り先 URL の確認、token の渡し方、認可先 URL の探索まで、どこを塞ぐべきか具体化している。 とくに confused deputy、per-client consent、token passthrough、SSRF は、remote MCP を local MCP の延長で入れると見落としやすい論点である。 つまり remote MCP の本体は transport の便利さではなく、『誰の承認結果を誰が使える構成なのか』を説明できることだ。 https://tinyaistudio.xyz/articles/gemini-model-names-operations-contract/ https://tinyaistudio.xyz/articles/gemini-model-names-operations-contract/ Fri, 19 Jun 2026 00:00:00 GMT Gemini の model 名は、賢さの札ではなく、どれくらい安心して本番に固定できるかを示す運用ラベルでもある。 危ないのは、便利だからという理由で `latest` alias や preview model をそのまま本番へ入れ、あとで回答変化の原因を追えなくすることだ。 公式は stable、preview、latest、experimental という名付けで変化前提を分けている。読むべきなのは性能表より、この変化条件の違いである。 preview model は docs 上で production 利用余地も残されているが、それは stable と同じ安心度で扱ってよいという意味ではない。 https://tinyaistudio.xyz/articles/mcp-inspector-debug-workflow/ https://tinyaistudio.xyz/articles/mcp-inspector-debug-workflow/ Fri, 19 Jun 2026 00:00:00 GMT MCP server の初期検証で危ないのは、Claude Desktop や IDE で一度返答しただけで『正しく動く』と判断してしまうことだ。 MCP Inspector は、読む機能、prompt、tool 実行、通知ログを分けて試し、どの層が壊れているかを切り分けやすくする検査用ツールである。 公式の best practices も、接続確認だけで終わらず、機能合意、入力不正、引数不足、同時実行、エラー応答まで試せと書いている。 つまり Inspector は viewer ではなく、『どこまで壊して確かめたか』を残せるデバッグ手順の中心である。 https://tinyaistudio.xyz/articles/function-calling-execution-boundary/ https://tinyaistudio.xyz/articles/function-calling-execution-boundary/ Thu, 18 Jun 2026 00:00:00 GMT AI に外部システムを触らせると、便利になる一方で『勝手に送る』『勝手に更新する』『間違った相手に処理する』という事故も起きうる。 だから最初に分けるべきなのは、情報を読むだけの操作と、何かを変更する操作である。読み取りは広めに許せても、書き込みは確認や制限が要る。 function calling は、その線引きを自然文のお願いで済ませず、AI が外部処理を呼ぶ入口をあらかじめ決めておく仕組みである。 OpenAI の guide は、AI に任せる部分と、アプリ側が必ず縛る部分を分けている。AI は呼び出し内容を提案し、実際に処理を走らせる責任はアプリ側に残る。 そのうえで、入力の形を固定する、使える処理を絞る、同時に走らせてよい処理を分ける、という実装上の制御が出てくる。 https://tinyaistudio.xyz/articles/claude-code-permissions-approval-boundary/ https://tinyaistudio.xyz/articles/claude-code-permissions-approval-boundary/ Thu, 18 Jun 2026 00:00:00 GMT coding agent を安全に使う難しさは、『危ない操作だけ確認してくれればよい』では済まないことにある。確認が多いほど、人は流れ作業で承認しやすくなる。 もう一つ危ないのは、禁止したつもりの操作が別の形で呼ばれることだ。command 名だけ見て止める運用では、回り道を見落としやすい。 Claude Code permissions は、毎回の気分で承認する代わりに、何を自動で許し、何を毎回聞き、何を最初から禁止するかを決めておく仕組みである。 docs の読みどころは、設定画面の使い方よりも、禁止ルールが許可ルールより強く働くこと、そして wrapper や symlink のような回り道まで考える必要があることだ。 hooks を入れても permissions の責任は消えない。事前検査と許可ルールを別々の層として持つほうが、実運用では説明しやすい。 https://tinyaistudio.xyz/articles/gemini-embeddings-meaning-search-layer/ https://tinyaistudio.xyz/articles/gemini-embeddings-meaning-search-layer/ Thu, 18 Jun 2026 00:00:00 GMT 検索で困るのは、必要な資料がないことだけではない。資料はあるのに、言い方が違うせいで見つからないことが多い。 embeddings は、この『言葉は違うが意味は近い』を拾うための下地である。ここが弱いと、後ろの生成 AI がいくら賢くても、最初に渡す資料を間違える。 まず決めるべきなのは model 名ではなく、自分のサービスで何を『近い』と見なしたいかだ。質問文と社内文書だけを比べるのか、PDF や画像も一緒に探したいのかで設計が変わる。 Gemini の新しい embeddings は、文字だけでなく画像、音声、動画、PDF も近さで比べる方向へ広がっている。つまり検索の対象が『文字に直した文書』だけではなくなっている。 ただし裏方部品だから軽く差し替えられるわけではない。古い embedding model で作った検索用データは、新しい model へ移ると作り直しが必要になる場合がある。 https://tinyaistudio.xyz/articles/file-search-responsibility-boundary/ https://tinyaistudio.xyz/articles/file-search-responsibility-boundary/ Wed, 17 Jun 2026 00:00:00 GMT 社内資料を AI に読ませる時、本当に難しいのは『検索を作れるか』より、『どこまでを外部サービスに任せ、どこを自分で持つか』を切ることだ。 OpenAI の File Search は便利機能紹介で終わらない。vector store、結果件数、metadata filtering、citation 表示まで含めて、managed retrieval の責任境界を API として見せている。 つまり RAG の性能競争より先に、文書更新、閲覧権限、出典表示、削除漏れを誰が持つかを決めろ、という原典として読む価値がある。 日本の小規模開発でありがちな『全部自作するか全部ベンダー任せにするか』の二択を崩し、検索基盤と文書ガバナンスを分けて考えさせる。 https://tinyaistudio.xyz/articles/claude-code-hooks-enforcement-boundary/ https://tinyaistudio.xyz/articles/claude-code-hooks-enforcement-boundary/ Wed, 17 Jun 2026 00:00:00 GMT prompt に『この command は使わないで』『編集後に formatter を回して』と書くだけでは、必ず守られる保証にはならない。 Claude Code hooks は、その弱さを埋めるために、禁止や必須処理を会話文ではなく決まった実行イベントへぶら下げる仕組みだ。 `PreToolUse` は実行前に止める、`PostToolUse` は実行後に整える、という役割分担が明確で、permission mode を緩めても deny 側の制約を残せる。 日本語圏で起きやすい『丁寧なプロンプトを書けば安全』という誤解を崩し、instruction と deterministic enforcement を分けて考えさせる。 https://tinyaistudio.xyz/articles/sandbox-agents-execution-boundary/ https://tinyaistudio.xyz/articles/sandbox-agents-execution-boundary/ Tue, 16 Jun 2026 00:00:00 GMT OpenAI が言いたいのは、『AI に作業させる箱』を本体アプリと同じ場所に雑に置くな、ということだ。 shell を使えるかどうかより重要なのは、考えて段取りを決める側と、実際に files や commands を触る側を分けることにある。 『前回の続き』も一種類ではない。会話の続きなのか、作業箱への再接続なのか、保存済み file 群の再利用なのかを分けて持てるようにしている。 日本の開発者にとっての読みどころは、agent に shell を混ぜる話ではなく、成果物の回収、再開方法、preview、credential 配置をどの境界に置くかという運用設計である。 https://tinyaistudio.xyz/articles/agentic-coding-benchmark-infra-noise/ https://tinyaistudio.xyz/articles/agentic-coding-benchmark-infra-noise/ Tue, 16 Jun 2026 00:00:00 GMT Anthropic は、AI coding benchmark の点差が『モデルの賢さ』だけでなく、マシン設定の違いでもかなり動くと示している。 特に危ないのは、必要最低限の資源量と強制終了ラインを同じ値にしてしまう運用だ。一瞬の負荷上振れだけで失敗し、モデルの実力と無関係な落第が混ざる。 余裕メモリのような実行環境のゆとりを少し増やすだけで、まず減るのは偽失敗であって、すぐにモデル能力が上がるわけではない。 leaderboard の小差を能力差と断定する前に、resource methodology と infra noise を疑え、というのがこの原典の実務的な読み方である。 https://tinyaistudio.xyz/articles/conversations-api-durable-state-object/ https://tinyaistudio.xyz/articles/conversations-api-durable-state-object/ Sun, 14 Jun 2026 00:00:00 GMT この guide の主題は『会話を続ける方法』そのものより、session や device や長時間 job をまたいでも使える state をどこに置くかである。 OpenAI は自動 state 管理の入口としてまず Responses API を勧めつつ、より長く共有したい状態には Conversations API という会話オブジェクトの持ち方も示している。 manual state 管理も残るが、`store=false` なら表示テキストだけを残せば済むわけではなく、必要な output items や reasoning item を戻す責任が増える。 日本の開発者にとっての実務価値は、便利な継続機能ではなく durable state、retention、compaction、監査の設計分岐として読める点にある。 https://tinyaistudio.xyz/articles/mcp-resources-read-only-context/ https://tinyaistudio.xyz/articles/mcp-resources-read-only-context/ Sat, 13 Jun 2026 00:00:00 GMT MCP Resources は、AI agent に読ませる資料と、実際に実行させる操作を分けるための仕様である。 要は「文書を読む入口」と「何かを実行する入口」を別にし、参照情報まで全部 tool に詰め込まないようにする面だ。 そのための仕組みとして、一覧を見る、本文を読む、条件付きで資料を組み立てる、更新を知らせる、といった面が protocol に定義されている。 日本で起きやすい『FAQ も schema も全部 tool』にする雑設計を、権限、UI、キャッシュ、監査の観点から引き上げる基礎仕様として読める。 https://tinyaistudio.xyz/articles/gemini-api-key-restrictions-migration/ https://tinyaistudio.xyz/articles/gemini-api-key-restrictions-migration/ Sat, 13 Jun 2026 00:00:00 GMT Google は、Gemini API の鍵を『とりあえず 1 本作って皆で使う』運用のまま放置するなと強く締め始めている。 2026-06-19 からは unrestricted standard key が拒否対象になり、さらに 2026-09 には standard key 自体が拒否対象になる予定なので、制限だけで終わらず auth key への移行も視野に入る。 Gemini 専用で使う鍵は AI Studio 側で Gemini API only に絞る導線がある一方、他の Google API と共有した鍵をそのまま使い回す設計は壊れやすい。 読者にとっての実務価値は、どの配布済み key がいつ止まりうるかを棚卸しし、雑な PoC 鍵運用を障害化する前に畳める点にある。 https://tinyaistudio.xyz/articles/prompt-objects-deprecation-governance/ https://tinyaistudio.xyz/articles/prompt-objects-deprecation-governance/ Sat, 13 Jun 2026 00:00:00 GMT OpenAI は、本番で使う prompt を管理画面に置き続ける運用から離れろと明確に言い始めた。 主張の中心は書き方変更ではなく、prompt 文面をコードレビュー、テスト、ロールバックが効く場所へ戻せという運用変更である。 公式には 2026-06-03 から prompt 作成の比重を下げ、`v1/prompts` は 2026-11-30 に停止予定だと案内している。 そのため prompt の変数管理、品質確認テスト、差分レビュー、同じ前半文面の再利用効率まで、repo 側で持つ前提へ寄せ直す必要がある。 https://tinyaistudio.xyz/articles/workload-identity-federation-short-lived-tokens/ https://tinyaistudio.xyz/articles/workload-identity-federation-short-lived-tokens/ Thu, 11 Jun 2026 00:00:00 GMT OpenAI は、CI や Kubernetes に長寿命 API key を置いて配る運用から離れるための案内を出している。 核心は、毎回その workload の身元を確かめたうえで、短時間だけ使える token を渡すことだ。 便利さより重要なのは、どの job なら本番権限を受け取れるかを細かく固定できる点で、ここが secret 配布との違いになる。 仕組みとしては、外部の認証基盤が出す一時的な身分証明を OpenAI 側の短命トークンへ交換し、どの job にどの権限を与えるかを対応付ける。 https://tinyaistudio.xyz/articles/inline-moderation-control-order/ https://tinyaistudio.xyz/articles/inline-moderation-control-order/ Thu, 11 Jun 2026 00:00:00 GMT OpenAI は、有害かもしれない内容を『生成後に別工程で止める』より、生成と近い場所で判断する運用へ寄せている。 重要なのは、危険ならあとで消すことではなく、表示前、保存前、外部送信前に止めやすくなった点だ。 単純な yes/no 判定だけでは足りず、どの種類の危険か、どの程度強いかを見て、自社ポリシーや人手レビューに結びつける必要がある。 実装上は、OpenAI の主要な生成 API の返り値の中に、安全判定も一緒に受け取れるようになった。 https://tinyaistudio.xyz/articles/gemini-interactions-steps-migration/ https://tinyaistudio.xyz/articles/gemini-interactions-steps-migration/ Wed, 10 Jun 2026 00:00:00 GMT Google は Gemini Interactions API の返り値の読み方を切り替え、古い形式を 2026-06-08 で外すと明記した。 怖いのは SDK 更新そのものより、返り値を読む自前コードや監視画面が静かに壊れることだ。 新しい `steps` 形式では、会話、tool 呼び出し、結果が時系列で並ぶため、アプリ側の読み方も変える必要がある。 function calling、構造化出力、streaming、会話履歴の引き継ぎを持つ実装ほど影響範囲が広い。 https://tinyaistudio.xyz/articles/secure-mcp-tunnel-private-server-boundary/ https://tinyaistudio.xyz/articles/secure-mcp-tunnel-private-server-boundary/ Wed, 10 Jun 2026 00:00:00 GMT 社内やローカルに置いた MCP サーバーを、インターネットへ丸出しにせず agent から使いたい人向けの公式ガイドである。 要は『内側のサーバーの近くから外へだけ接続し、外から直接入ってこない形』に整理する仕組みだ。 その役を担うのが `tunnel-client` で、MCP サーバーに届く境界の内側で動き、OpenAI 側との中継点になる。 重要なのは接続のしやすさより、どこまでを OpenAI に任せ、どこから先を自社の認証、監査、権限管理で持つかを説明しやすくした点にある。 https://tinyaistudio.xyz/articles/background-mode-job-control/ https://tinyaistudio.xyz/articles/background-mode-job-control/ Thu, 11 Jun 2026 00:00:00 GMT OpenAI の background mode は、数分かかる AI タスクを『接続を開いたまま待つ処理』ではなく、後から追跡するジョブとして扱う考え方をはっきり示している。 重要なのは timeout 回避だけではない。依頼受付、処理中、完了、キャンセル済みを前提に、アプリ側の仕事の流れを変える必要がある。 guide は、結果をしばらく保持して追跡を成立させる都合上、Zero Data Retention 互換ではないと明記している。 技術的には Responses API で `background=true`、polling、streaming 再接続、cancel を組み合わせるが、進捗表示や失敗時再試行まで設計しないと片手落ちになる。 https://tinyaistudio.xyz/articles/mcp-roots-permission-boundary/ https://tinyaistudio.xyz/articles/mcp-roots-permission-boundary/ Thu, 11 Jun 2026 00:00:00 GMT MCP Roots は、AI agent に『このフォルダだけ見てよい』と伝えるための標準的な境界表現だ。 重要なのは tool 接続そのものではなく、server が見てよい workspace 範囲を protocol の中で共有できる点にある。 そのため client は見せる作業領域を先に出し、server はその外を前提にしない設計を取りやすくなる。 技術的には client が `roots` capability を宣言し、server が `roots/list` で一覧を取得し、必要なら `notifications/roots/list_changed` で変更通知を受ける。 https://tinyaistudio.xyz/articles/gemini-managed-agents-sandbox-boundary/ https://tinyaistudio.xyz/articles/gemini-managed-agents-sandbox-boundary/ Wed, 10 Jun 2026 00:00:00 GMT Gemini API の managed agents は、1回の API call で Linux sandbox を起動し、その中で推論、コード実行、ファイル操作、web browsing まで進める agent harness として出てきている。 重要なのは agent 自体より、Google-hosted sandbox が OS level isolation を持ちながらも、default では unrestricted outbound network access で動くと明記している点。 allowlist、credential scoping、review-before-rely を自前で置かない限り、『sandbox があるから安全』という理解は成立しない。 日本の開発者や PM にとっての論点はモデル比較ではなく、Google-hosted execution を使うなら、どの資格情報を渡し、どの外向き通信を許し、どの業務では人間レビューを外せないかである。 https://tinyaistudio.xyz/articles/claude-containment-blast-radius/ https://tinyaistudio.xyz/articles/claude-containment-blast-radius/ Mon, 08 Jun 2026 00:00:00 GMT Anthropic は agent の安全性を『危険行動を完全に止めること』ではなく、『危険行動しても届く範囲を狭くすること』で説明している。 claude.ai、Claude Code、Claude Cowork で containment の形が違う理由を示し、同じ承認 UI を全ユーザーに当てても安全にならないと整理している。 未信頼ディレクトリの設定読み込み、ユーザー経由の prompt injection、許可済みドメイン経由のデータ流出という失敗例が具体的に書かれている。 日本の開発者や PM が読むべき論点は、agent をどこまで賢くするかではなく、認証情報、社内データ、書き込み権限、外部送信をどこで切るかである。 https://tinyaistudio.xyz/articles/gpt-realtime-voice-models/ https://tinyaistudio.xyz/articles/gpt-realtime-voice-models/ Mon, 08 Jun 2026 00:00:00 GMT OpenAI は GPT-Realtime-2、GPT-Realtime-Translate、GPT-Realtime-Whisper という音声向け API モデル群を発表した。 重要点は音声の自然さだけでなく、会話中の推論、ツール実行、回復動作、長い context を前提にした voice agent 設計へ寄っていること。 開発者は preamble、parallel tool calls、reasoning effort、128K context などを UX と運用責任の両面で見る必要がある。 日本で使うなら、予約、問い合わせ、通訳、社内業務音声化の前に、同意、ログ、失敗時停止、音声品質の eval を先に置くべき。 https://tinyaistudio.xyz/articles/responses-api-mcp-tools/ https://tinyaistudio.xyz/articles/responses-api-mcp-tools/ Mon, 08 Jun 2026 00:00:00 GMT OpenAI は Responses API に remote MCP servers、image generation、Code Interpreter、file search 改善などを追加した。 単なるチャット API ではなく、agentic application を組むための実行基盤としての色が強まっている。 日本の開発チームは「モデルに何を任せるか」より先に、権限・監査・失敗時処理を設計する必要がある。 https://tinyaistudio.xyz/articles/claude-code-quality-postmortem/ https://tinyaistudio.xyz/articles/claude-code-quality-postmortem/ Mon, 08 Jun 2026 00:00:00 GMT Anthropic は Claude Code、Claude Agent SDK、Claude Cowork に関する品質報告の原因と対応を説明した。 品質低下はモデルそのものだけでなく、推論 effort、ツール設定、プロダクト側変更でも起きる。 AI coding tool を業務に入れるなら、利用者の体感品質を拾う仕組みが不可欠になる。 https://tinyaistudio.xyz/articles/gemini-api-release-notes-reading/ https://tinyaistudio.xyz/articles/gemini-api-release-notes-reading/ Mon, 08 Jun 2026 00:00:00 GMT Gemini API の changelog は、モデル、SDK、OpenAI compatibility、構造化出力などの変更確認に使える。 AI Studio の画面だけで判断せず、API 仕様の変更を source として追うことが重要になる。 日本の開発者は、サンプルコードより先に利用モデル、rate limit、deprecation を確認すべき。 https://tinyaistudio.xyz/articles/huggingface-tiny-agents-mcp/ https://tinyaistudio.xyz/articles/huggingface-tiny-agents-mcp/ Mon, 08 Jun 2026 00:00:00 GMT Hugging Face は MCP を使った小さな agent 実装を紹介している。 agent の本質を巨大フレームワークではなく、tool discovery と while loop として理解できる。 日本の開発者が agent を学ぶには、最初に小さな実装で責任分界を見る方が速い。 https://tinyaistudio.xyz/articles/mcp-architecture-overview/ https://tinyaistudio.xyz/articles/mcp-architecture-overview/ Mon, 08 Jun 2026 00:00:00 GMT MCP は AI application と外部 tool/data を接続する client-server architecture として説明される。 よく語られる tools だけでなく、resources、prompts、notifications などの primitive がある。 日本語では『AI 用の外部ツール規格』だけでなく、『context の渡し方を標準化する層』として理解したい。