補助的なコーディングから Agentic Coding へ：チームは AI プログラミングをどう本当に活用するのか

郭立（Leo） · 2026年3月18日 · 更新 2026年10月9日 · 33分で読めます

1. AI プログラミング / Agentic Coding とは何か

AI プログラミングは、もはや「数行のコードを補完する」だけのものではありません。

以前 AI coding と言うと、IDE の中で補完したり、コードを説明したり、関数を生成したりすることを指す場合が多くありました。現在の Agentic Coding は、AI がコードを生成するだけでなく、1つの目標をめぐって継続的に作業できることを指します。つまり、コードベースを読み、規約を理解し、タスクを分解し、ファイルを修正し、コマンドを実行し、テストを走らせ、結果を報告し、人間のレビューを待つ、という流れです。

これは従来の「問答式 AI」とは次の点で異なります。

操作対象はテキストだけではなく、コードベース、ターミナル、テスト、ドキュメント、タスクフローです。
受け取る入力は単なる prompt ではなく、リポジトリのコンテキスト、チーム規約、ツール権限、実行境界です。
出力はコード片だけではなく、レビュー可能なプロセスと結果です。

OpenAI は「Introducing Codex」の中で、Codex を独立したクラウドサンドボックス内でタスクを並列処理できるソフトウェアエンジニアリング agent と定義し、リポジトリ内の AGENTS.md が、コードベースのナビゲーション方法、テストの実行方法、プロジェクト規約の遵守方法を agent に伝えられることを明確に強調しています。Anthropic は「Claude Code overview」の中で、この種のツールをより直接的に定義しています。コードを読み、ファイルを変更し、コマンドを実行し、MCP に接続し、プロジェクト情報を記憶し、カスタムコマンドや hooks を使ってチームのワークフローを実行できる、というものです。

一言で言えば、AI プログラミングの重点は「コードを書けるかどうか」から、「実際のエンジニアリング環境で安定してタスクを完了できるか」へと移っています。

2. 現在の主流ツールはどのような姿か

今日の AI プログラミングツールは、大きく 4 つのカテゴリに分けられます。

2.1 IDE インライン補完型

典型的な代表例は、Cursor、GitHub Copilot、Windsurf のような IDE 内ツールです。

これらの強みは次のとおりです。

速く、日常的なコーディング、補完、局所的な修正に向いている
ほとんど心の流れを中断しない
「強化版エディタ」に近い

一方で、弱点も明確です。

局所的なタスクには向いているが、長い一連のタスクは得意ではない
コンテキストは通常、現在のファイルや現在のセッションを中心にしている
「複数ステップの実行」への対応は限定的

2.2 ターミナル Agent 型

典型的な代表例は、Codex CLI / App、Claude Code です。

この種のツールの特徴は次のとおりです。

ターミナルやサンドボックス内で直接作業する
複数のファイルやディレクトリをまたいでタスクを完了できる
コマンドを実行し、コードをテストし、ログを調べ、変更を生成できる
「補完プラグイン」ではなく「共同開発者」により近い

これこそが、現在 Agentic Coding の中で最も注目すべき方向性です。

2.3 マルチ Agent / 非同期協作型

OpenAI は「Introducing the Codex app」の中で、Codex app を「agent command center」と定義しています。

このカテゴリのツールの核心は、単発の生成ではなく、次のような点にあります。

複数 agent の並列実行
worktree / 隔離されたコピー
長いタスクの非同期実行
review queue
automations の定期実行

これは、チームが「私と 1 つの AI が対話する」段階から、「私が一群の agent に仕事を割り振る」段階へ入り始めていることを意味します。

2.4 企業プロセス接続型

本当に成熟した実装は、IDE やターミナルそのものにとどまらず、さらに下流へ接続されていきます。

issue / ticket
design
docs
CI
release
review

OpenAI の「How OpenAI uses Codex」と Anthropic の Claude Code ドキュメントはいずれも、同じことを強調しています。AI プログラミングは孤立したツールではなく、研究開発プロセスに接続される実行ノードです。

3. なぜ「コンテキストエンジニアリング」はモデルのパラメータより重要なのか

モデルが上限を決めるのだとすれば、コンテキストエンジニアリングは下限を決めます。

同じ agent でも、規範も境界もツール制約もないリポジトリでは、しばしば「正しそうに見える」結果しか出せません。一方で、チームのルール、よく使うコマンド、外部依存、反復的なフローをきちんと固定しておくと、その安定性は明らかに向上します。

だからこそ私は、チームにはまず次のものを優先して整備することを勧めています。

AGENTS.md
Skill
MCP

逆ではありません。

3.1 `AGENTS.md` は最も基礎的な永続コンテキスト

AGENTS.md の価値は、「毎回また説明しなければならないこと」をリポジトリに固定できる点にあります。

入れるのに最も適している内容は、たとえば次のようなものです。

リポジトリ構造をどう理解すべきか
どのディレクトリは変更してよく、どこは触るべきでないか
テストやビルドを実行する標準コマンド
コードスタイル、コミット規約、レビュー要件
コードを読むだけでは推測できない過去の落とし穴や事業上の制約

OpenAI は「Introducing Codex」と「How OpenAI uses Codex」のどちらでも、AGENTS.md の役割を明確に強調しています。これは agent に、継続的で安定した、タスクをまたいだリポジトリコンテキストを与えられるものです。

チームにとって、AGENTS.md が解決するのは認識合わせの問題です。

3.2 なぜ私はチームに Skill の優先利用を勧めるのか

OpenAI は「Introducing the Codex app」で、skill を非常に明確に定義しています。skills bundle instructions, resources, and scripts。つまり skill は単なる一文の prompt ではなく、再利用可能で、実行可能で、共有可能な作業単位です。

私が MCP をデフォルトの答えにするのではなく、Skill をより勧める主な理由は 5 つあります。

1. Skill はチームの方法論を蓄積するのに向いている

チームが本当に再利用したいものは、多くの場合「どこかのシステムにつなぐこと」ではありません。たとえば次のようなものです。

code review をどう行うか
changelog をどう書くか
API ドキュメントをどう同期するか
本番障害をどう調査するか
リリース前チェックをどう行うか

これらの本質は、方法、手順、制約、スクリプトであって、「外部システムへの接続プロトコル」ではありません。

Skill は、まさにこうした内容を載せるのに適しています。

2. Skill はバージョン管理とレビューがしやすい

Skill はそのままリポジトリに入れ、コードと一緒にレビュー、反復、ロールバックできます。

これはチームにとって非常に重要です。なぜなら、次のことを意味するからです。

変更を追跡できる
ルールをレビューできる
経験を継承できる
新メンバーが再利用できる

OpenAI も、skills は app、CLI、IDE extension の間で再利用でき、リポジトリに check in してチームで共有することもできる、と明確に書いています。

3. Skill は通常、権限面が小さい

多くの Skill の中心は次のものです。

指示
ローカルリソース
既知のスクリプト
固定されたワークフロー

それに対して MCP は、しばしば次のものを意味します。

追加の server
リモート接続
外部認証
リアルタイムデータアクセス
実行可能なツール呼び出し

チームガバナンスの観点では、Skill のほうが通常、権限の収束とリスクコントロールを行いやすいです。

4. Skill は再現性が高い

Skill は「標準作業手順」に近いものです。

入力条件がだいたい同じであれば、出力までの経路も比較的安定します。たとえば次のようなものを作りやすくなります。

プロジェクト onboarding skill
リリースチェック skill
API ドキュメント同期 skill
障害調査 skill

こうした資産の価値は、一回限りの prompt よりはるかに高いです。

5. Skill はまず導入し、その後拡張するのに向いている

多くのチームは最初から MCP を議論しますが、最後には次のようなところで詰まりがちです。

server をどうデプロイするか
認証をどう管理するか
データをどう認可するか
どの tool を実行可能にするか
監査をどう行うか
問題発生時にどう調査するか

一方、Skill は始めるハードルがずっと低いです。高頻度のフローをまず Skill 化するだけで、チームはすでに 70% の利益を得られます。

3.3 MCP とは何か。有用だが、デフォルトの答えではない

MCP の公式仕様は非常に明確に定義しています。これは host / client / server アーキテクチャであり、JSON-RPC ベースのコンテキストとツールの交換プロトコルです。提供される中核的なプリミティブには次のものがあります。

resources
prompts
tools
sampling

したがって、MCP は「プロトコル層」や「接続層」に近いものであり、チームの方法論ではありません。

もちろん有用です。特に次のような場面に適しています。

Figma、Google Drive、Jira、Slack、Linear などの外部システムを読む
AI をリアルタイムデータソースにつなぐ
明確なツール呼び出しインターフェースを公開する
複数の agent / host の間で統一的な接続を行う

ただし、当然ながら欠点もあります。

3.4 MCP のいくつかの現実的な問題

以下の判断は、MCP の公式仕様、OpenAI / Anthropic のドキュメント、そして実際のチームでの導入経験に基づく私の整理です。

1. MCP が解決するのは「接続」であって「方法」ではない

MCP は、agent にリソースの取り方やツールの呼び出し方を教えることはできます。しかし、チームに対して次のことは教えてくれません。

review をどう行うか
コード規約をどう実行するか
どのコマンドを走らせるべきか
どの手順で必ず人間の確認が必要か

これらはやはり AGENTS.md と Skill で補う必要があります。

2. MCP はガバナンスコストが高い

MCP を導入すると、導入するのは単なる「能力」ではなく、追加の複雑性をまるごと一式抱えることになります。

host / client / server の関係
capability negotiation
認証と権限
サービス可用性
呼び出し失敗とリトライ
監査と責任追跡

多くのチームにとって、この層の複雑性は割に合いません。

3. MCP はセキュリティ面が広い

MCP はしばしば外部システムや実行可能ツールに接続します。

これは、追加で次のことを考えなければならないという意味です。

どのデータを server に公開してよいか
どのツールを呼び出してよいか
リモート server は信頼できるか
ネットワークアクセスをどう制限するか
prompt injection 後に影響範囲が拡大しないか

MCP の公式仕様自体も、user consent、data privacy、host 側のセキュリティ境界を強調しています。言い換えれば、仕様そのものが、これは高リスク面であることを前提にしています。

4. MCP はプロジェクト内の暗黙知ルールを載せるのに向いていない

プロジェクトで最も重要なものは、多くの場合 Jira ticket や Figma のデザインではなく、「チームだけが知っている」制約です。

あるモジュールの過去の負債
あるディレクトリは触ってはいけない
あるフィールドは変更してはいけない
特定のテストは必ず実行する
特定タイプの問題では、まずどのログを見るべきか

こうしたものは MCP server に詰め込むより、AGENTS.md や Skill に書くほうが向いています。

3.5 より実用的な優先順位

チーム導入を目標にするなら、私は次の優先順位を勧めます。

まず AGENTS.md をきちんと書く
高頻度フローを Skill 化する
リアルタイムの外部システムが本当に必要な場合にだけ MCP を接続する

つまり、次のようになります。

AGENTS.md は「このプロジェクトをどう進めるべきか」を解決する
Skill は「この作業をどう繰り返し安定して行うか」を解決する
MCP は「この作業を外部システムにつないで行う必要がある」を解決する

この順序のほうが安定しており、チーム展開にも向いています。

3.6 原理：モデルはいつ MCP、Skill、`CLAUDE.md`、`AGENTS.md` を使うべきかをどう知るのか

ここは最も話が曖昧になりやすい部分です。

多くの共有では、これらを全部ひとまとめにして「モデルにコンテキストを食わせるもの」と説明します。しかしそれは十分に正確ではありません。これらは原理、トリガー方法、制御権が実際にはまったく異なります。

まず最も重要な判断を示します。

仕組み	本質	誰がトリガーを制御するか	いつコンテキストに入るか
`AGENTS.md`	リポジトリ単位の永続的な説明書	agent / ホストがタスク開始時に読む	通常、repo タスク開始時に永続コンテキストとして入る
`CLAUDE.md`	プロジェクト / ユーザー / 組織単位の永続的な説明書	Claude Code が起動時やディレクトリ読み取り時にロード	起動時にロードされる。サブディレクトリのルールは必要に応じてロードされる
Skill	再利用可能なワークフローパッケージ	モデルが説明に基づいてマッチングする、またはユーザーが明示指定する	まずメタデータだけをロードし、ヒット後に本文とリソースをロードする
MCP Prompts	テンプレート化された prompt	ユーザーが制御	ユーザーが選択または実行したときに入る
MCP Resources	外部リソース参照	ホスト / アプリが制御。ユーザーが明示的に参照することもできる	添付または参照されたときに入る
MCP Tools	外部ツール呼び出しインターフェース	モデルが制御するが、権限はホストが担う	モデルが呼び出すと判断したときにだけ実行される

3.7 MCP の原理とは何か

MCP は「1 つのプラグイン」ではなく、プロトコルのセットです。

公式仕様では、MCP は host / client / server アーキテクチャとして定義されています。

host は調整、認可、安全ポリシーの実行を担う
client は host を代表して特定の server に接続する
server は prompts、resources、tools などの能力を公開する

MCP の基礎通信は JSON-RPC です。標準的な lifecycle はかなり明確です。

まず initialize
capability negotiation を行う
その後、通常の operation に入る

つまり、モデルが最初から「すべてのツールを知っている」わけではありません。まずホストが利用可能な能力を交渉し、その後でモデルとアプリがその境界内で動作します。

3.8 MCP は実際にはどうトリガーされるのか

ここは 3 種類に分けて見る必要があります。公式仕様でははっきり書かれています。

Prompts は user-controlled
Resources は application-controlled
Tools は model-controlled

この 3 種類はどれも「能力」のように見えますが、トリガーの仕組みはまったく異なります。

3.8.1 MCP Prompts：ユーザーがトリガーする

MCP prompt は、再利用可能なテンプレートコマンドに近いものです。

通常、次のようなタイミングでトリガーされます。

ユーザーがメニューから選ぶ
ユーザーが slash command を実行する
ユーザーが特定の prompt テンプレートを明示的に呼び出す

したがって prompt はモデルがこっそり勝手に使うものではなく、ユーザーが選び、ホストがテンプレートを展開してモデルに渡すものです。

3.8.2 MCP Resources：アプリまたはユーザーが参照したときにトリガーされる

Resource はコンテキストであり、アクションではありません。

典型的なトリガー方法は 2 つあります。

ホストが自動的に添付する
ユーザーが明示的に参照する

Anthropic の Claude Code ドキュメントには、かなり具体的な例があります。MCP resource はファイルのように @server:protocol://path で参照できます。一度参照されると、リソースは自動的に取得され、attachment としてコンテキストに入ります。

つまり resource の本質は「モデルに実行させる」ことではなく、外部コンテンツをモデルに読ませることです。

3.8.3 MCP Tools：モデルが呼び出すかどうかを判断する

Tool こそが、本当の意味で「agent が外部世界で手を動かす」ことに最も近い層です。

MCP 公式仕様によれば、tool は model-controlled です。つまり、次のようになります。

ホストがまず呼び出し可能なツールを公開する
モデルが推論過程で、それを使う必要があるか判断する
実際の実行前後では、依然としてホストが権限、隔離、確認、ログを担う

したがって「モデルはどう MCP をトリガーするのか」という言い方が厳密に成り立つのは tools 部分だけです。prompts と resources については、同じトリガーロジックではありません。

3.9 Skill の原理とは何か

Skill は外部接続プロトコルではなく、ロード可能なワークフローパッケージです。

OpenAI は《Introducing the Codex app》の中で、skills は instructions、resources、scripts を bundle するものだと定義しています。Anthropic の Agent Skills ドキュメントでは、さらに細かく原理を説明しています。Skill は VM / ファイルシステム内のディレクトリであり、その中に SKILL.md、スクリプト、参考資料を置き、Claude は progressive disclosure によって段階的にロードします。

これは非常に重要です。なぜなら、Skill がチーム導入に向いている理由を説明しているからです。

Skill の本質は「外部システムを接続する」ことではなく、次のようなものです。

チームの方法論をパッケージ化する
説明、リソース、スクリプトを同じ単位にまとめる
モデルが必要なときだけロードし、常にコンテキストを占有しないようにする

3.10 Skill はどうトリガーされるのか

3.10.1 OpenAI / Codex の公開説明

2026 年 2 月 2 日時点の OpenAI《Introducing the Codex app》では、公式の公開説明として次のように述べられています。

Codex に特定の skill を使うよう明示的に要求できる
現在のタスクに応じて自動的に使わせることもできる

OpenAI の公開資料では現時点で、Anthropic のように内部ロードの階層的な仕組みまでは細かく書かれていません。公開情報に基づくなら、比較的堅実な理解は次のとおりです。

skill には少なくとも「発見可能な説明情報」がある
agent はタスクの意味に基づいて skill ルーティングを行う
ヒット後、その skill 内の instructions / resources / scripts を使用する

最後の 2 点は公開されている挙動に基づく推論であり、OpenAI が現時点の公開ドキュメントで実装詳細として逐条的に明記しているものではありません。

3.10.2 Anthropic / Claude の公開説明

Anthropic はこの部分をより詳しく公開しています。

公式ドキュメントでは、Skill のトリガーは 3 層として説明されています。

Metadata は常駐ロードされる
name と description は起動時にシステムプロンプトへ入り、発見とマッチングに使われる。
SKILL.md 本文 はトリガー時にロードされる
ユーザーのリクエストが skill の説明と一致したときにだけ、Claude は SKILL.md を読む。
追加リソースとスクリプト は必要に応じてロードされる
本文内で追加ドキュメントやスクリプトが参照された場合にだけ、Claude はさらに読み取りまたは実行する。

これが典型的な progressive disclosure です。

つまり、Skill のトリガーは「skill パッケージ全体が常にコンテキストに入る」というものではありません。

まず「どんな skill があるか」を知る
次に「現在のタスクがこの skill に似ているか」を判断する
ヒットしてから説明書を読む
さらに材料が必要になったときに、追加で展開する

これこそが、Skill が「長大なシステムプロンプト」より効率的である根本的な理由です。

3.11 `CLAUDE.md` は何のためのものか、いつ使われるのか

CLAUDE.md はコマンドでもプラグインでもなく、Claude Code の永続指示ファイルです。

Anthropic の公式ドキュメントは非常に直接的に説明しています。

CLAUDE.md は、プロジェクトルール、ワークフロー、アーキテクチャ情報を Claude に継続的に伝えるために使われる
Claude は各 session の開始時に読み取る
上位ディレクトリの CLAUDE.md は、起動時に丸ごとロードされる
サブディレクトリ内の CLAUDE.md は、Claude が対応するディレクトリのファイルを読んだときに必要に応じてロードされる

さらに重要なのは、Anthropic がこれを auto memory と区別している点です。

CLAUDE.md は、あなたが書く instructions and rules
auto memory は、Claude 自身が蓄積する learnings and patterns

つまり、CLAUDE.md の原理は「記憶庫」ではなく、あなたが手作業で管理し、レビュー可能で、session をまたいで有効になる体系的な説明書です。

「大規模言語モデルはいつ CLAUDE.md を使うのか」と聞くなら、最も正確な答えは次のとおりです。

セッション開始時点で使われる
特定のディレクトリに入る / 特定のファイルを読むときに、より細かい粒度のルールが追加でロードされる
モデルが一時的に思いついて探しに行くのではなく、Claude Code のコンテキストロード機構そのものが処理する

Anthropic はさらに .claude/rules/ という層も追加しています。

パス制限のないルールは、起動時にロードされる
paths 付きのルールは、マッチするファイルが読み取られたときにだけトリガーされる
公式はさらに、「タスク型であり、常駐型ではない」説明は、常駐 rules に全部詰め込むのではなく、Skill を優先すべきだと明確に書いている

これはかなり参考にすべき点です。

3.12 `AGENTS.md` は何のためのものか、いつ使われるのか

まず名前を 1 つ訂正します。

2025年5月16日時点の OpenAI「Introducing Codex」と、2025年10月の「How OpenAI uses Codex」の公開資料によれば、OpenAI 公式が使っている名称は AGENTS.md であり、agent.md ではありません。

Codex 体系における AGENTS.md の役割は、CLAUDE.md と非常に近いものですが、公開されている詳細は Anthropic ほど細かくありません。

OpenAI 公式がすでに明確に公開している点は 2 つあります。

AGENTS.md は、Codex にコードベースの歩き方、実行すべきテスト、従うべきプロジェクト規約を伝えられる
Codex に persistent context を提供できる

これは、本質的に リポジトリ単位の永続的な説明ファイル でもあることを示しています。

ただし注意すべきなのは、OpenAI の公開資料では今のところ、Anthropic のように「ロード順、サブディレクトリでのオンデマンドロード、パスルールによるトリガー」まで明確には書かれていないという点です。

したがって、より堅実な結論は次のとおりです。

AGENTS.md は、Codex が repo タスクを処理するときに継続的なコンテキストとして参照される
プロジェクト規約、コマンド、境界、アーキテクチャ上のヒントを置くのに適している
「外部ツールのトリガー」ではなく、「聞かれたときだけ一時的にロードされる知識ブロック」でもない

さらに一歩踏み込んで「Codex がいつ必ず AGENTS.md をロードするのか、必ずどの順序でマージするのか」と言ってしまうと、それは現時点の公開資料を超えています。この部分は 実装レイヤーでの推論 にとどまり、確定的な結論として書くのには向いていません。

3.13 この 4 種類の仕組みを一文で言い切る

共有の場でこれらを一言で区別するなら、私は次のように説明することをおすすめします。

AGENTS.md / CLAUDE.md：リポジトリやプロジェクトの 長期的な説明書
Skill：タスクに応じてトリガーされる ワークフローパッケージ
MCP Resource：外部システムの 参照可能なコンテキスト
MCP Tool：モデルが境界内で呼び出せる アクションインターフェース

この 4 つを区別できれば、「AI プログラミングがなぜあるときは非常に強く、あるときは妙に鈍いのか」という多くの現象も説明できるようになります。

4. 安全性、サンドボックス、権限制御をどう設計するか

AI プログラミングでは、効率だけを語るわけにはいきません。必ず境界についても語る必要があります。

なぜなら、agent がファイルを読み、コードを変更し、コマンドを実行し、ネットワークに接続できるようになった時点で、そのリスクモデルは通常のチャットボットとはまったく異なるものになるからです。

Anthropic は「Making Claude Code more secure and autonomous with sandboxing」で、この点を非常に明確に説明しています。真に重要なのは、次の 2 層の隔離です。

ファイルシステムの隔離
ネットワークの隔離

この 2 層が同時に備わって初めて、「agent により安全に自律実行させる」と言えるようになります。

OpenAI も「Introducing the Codex app」で同じ方向性を示しています。デフォルトでは agent が作業ディレクトリ内のファイルだけを編集できるようにし、ネットワークは制限し、境界を超えるコマンドについては改めて承認を求める、という考え方です。

チームで導入する場合、少なくとも次の点は満たすことをおすすめします。

4.1 デフォルトは最小権限にする

最初の設定としては、次の形をおすすめします。

デフォルトは読み取り専用
デフォルトでは現在の作業ディレクトリだけを許可
デフォルトではネットワーク禁止、またはキャッシュ検索のみ許可
デフォルトでは高リスクなコマンドを許可しない

最初から agent にディスク全体の読み書き権限や自由なネットワーク接続を与えるべきではありません。

4.2 ファイルシステムの境界を明確にする

最も基本的な制限には、次のようなものがあります。

現在の repo または現在の worktree だけを変更可能にする
機密ディレクトリへのアクセスを禁止する
SSH key、署名鍵、グローバル設定には触れさせない
生成物ディレクトリ、キャッシュディレクトリ、一時ディレクトリを個別に制約する

4.3 ネットワーク権限はホワイトリスト化する

agent にネットワーク接続を許可する場合は、明確なドメインだけを開放するのが望ましいです。

ドキュメントサイト
パッケージリポジトリ
指定された API
指定された内部サービス

「任意の外部通信」は許可しないでください。

4.4 あらゆる越権は可視化されるべき

理想的な状態とは、「絶対に間違えない」ことではありません。むしろ次の状態です。

境界を越えた瞬間に止められる
すべてのステップにログが残る
どのコマンドを実行したか追跡できる
どの出力を見たか後から確認できる

これは単に「モデルを信頼する」ことよりも重要です。

4.5 高リスクな操作は人間に残す

次のような操作は、デフォルトで人間の確認を必要とする形にしておくことをおすすめします。

リモートブランチへの push
本番設定の変更
大量のファイル削除
データベース変更の実行
実際の本番環境への書き込み API 呼び出し
機密性の高い業務データへのアクセス

Agent は操作の準備まではできますが、最後の一手は自動化しないほうがよいです。

5. 効果をどう測るか、デモだけを見ない

AI コーディングでチームが最も誤解しやすいのは、demo がどれも強力に見えることです。

しかし本当に答えるべき問いは、「それが例を 1 つ作れるか」ではありません。むしろ次の問いです。

実際のタスクを安定して処理できるか
チーム環境で再現できるか
どれだけの手戻りとレビューコストを持ち込むか
本当に効率化しているのか、それともコストを後ろへずらしているだけなのか

5.1 外部 benchmark で何が見えるか

SWE-bench は、現時点で最も引用する価値のある公開 benchmark の 1 つです。

その価値は次の点にあります。

実際の GitHub issue を使っている
再現可能な Docker 評価環境がある
「本当に問題を解決し、テストに通るか」を見ている
それらしいコード片を生成できるかだけを比べているわけではない

この種の benchmark は、AI コーディングの評価をデモ動画や単発のサンプルだけで判断してはいけない理由を説明するのに非常に適しています。

5.2 しかしチームは benchmark だけを見てはいけない

SWE-bench が解決しているのは、「公開タスクにおけるモデル / agent の能力比較」です。「あなたのチームがすでに効率化できている」ことと同じではありません。

チームが本当に見るべきなのは、自分たちの内部指標です。

5.3 より追跡すべき 8 つの指標

私なら、チームには次の指標を追うことをおすすめします。

指標	答えるべき問い
最初の利用可能な patch までの時間	agent がレビュー可能な初版をどれだけ早く出せるか
タスク完了率	与えられたタスクが最終的に完了したか
一回でのマージ率	初回の成果物がマージ可能な状態からどれだけ離れているか
人手による手戻り時間	結果を納品可能な状態に直すために、人が追加でどれだけ時間を使ったか
テスト通過率	agent が自発的にテストを追加し、テストを実行し、失敗を修正するか
レビュー差し戻し率	コード品質、規約、境界条件の処理が安定しているか
ドキュメント同期率	コード変更後に、ドキュメント、変更履歴、API 仕様が追従しているか
セキュリティ越権回数	agent が権限境界を越えようとした回数

これらの指標は、「生成速度が速い」「賢そうに見える」よりもはるかに有用です。

5.4 シンプルな評価の階層

私は、AI コーディングの評価を 3 層に分けることをおすすめします。

第一層：公開 benchmark

SWE-bench などを使って、モデルや agent の汎用的な上限を見る。

第二層：チーム標準タスク集

固定タスクのセットを自分たちで作ります。たとえば次のようなものです。

実際の bug を 1 つ修正する
API フィールドを 1 つ追加し、ドキュメントも同期する
テストを 1 セット追加する
リファクタリングを 1 回行う
本番アラートを 1 件処理する

この層が最も重要です。

第三層：実際の開発指標

最終的には次を見ます。

デリバリーサイクルは短くなったか
手戻り率は下がったか
本番事故は増えていないか
ドキュメントとプロセスはより完全になったか

第三層が改善して初めて、AI コーディングは本当に現場に定着したと言えます。

6. チーム導入の提案：まず Skill、その後 MCP

もしチームに非常に実務的な導入順序を提案するなら、私は次のように進めることをおすすめします。

第一歩：まず `AGENTS.md` を正しく書く

少なくとも次を明確に書きます。

プロジェクト構成
主要コマンド
テストとビルドの方法
触れてはいけない境界
コミットとレビューの要件

第二歩：高頻度タスクを Skill 化する

優先的に Skill 化する価値が最も高いのは、通常次のようなものです。

code review
changelog 生成
リリースチェック
API ドキュメント同期
問題調査
新メンバー onboarding

第三歩：「外部システム連携が必須」の能力だけ MCP につなぐ

たとえば次のようなものです。

Figma
Jira / Linear
ドキュメントライブラリ
読み取り専用データシステム

すべてを MCP に詰め込まないでください。

第四歩：自動化と multi-agent は最後に検討する

AGENTS.md、Skill、安全境界、評価方法がある程度安定してから、次を導入します。

automations
multi-agent
長時間タスクの非同期実行
定期巡回チェック

この順序のほうが、「先に大量のツールをつないで、あとから少しずつガバナンスを補う」よりも、はるかに堅実です。

7. 共有しやすい核心的な結論

今回の共有で 4 文だけ残すなら、私はこの 4 つを話すことをおすすめします。

AI プログラミングはすでに「コード補完」から「Agentic Coding」へ移行しており、焦点は実際のエンジニアリング環境でタスクを完了できるかどうかにあります。
チーム導入の鍵はモデルのパラメータではなく、コンテキストエンジニアリング、とくに AGENTS.md と Skill です。
MCP は非常に有用ですが、外部システム連携により適しており、チームの方法論を代替すべきではありません。デフォルトの優先順位は AGENTS.md > Skill > MCP にすべきです。
AI プログラミングの評価は demo だけを見るのではなく、サンドボックス、安全境界、実タスクの完了率、長期的な開発指標を見るべきです。

付録：主要参考資料

まず消化する価値が最も高い 5 本

補足に適した資料

二次参考レイヤー：講演、共有、経験談をどう取り入れるか

この種の資料は非常に価値がありますが、使い方は分けて考える必要があります。

私のおすすめは、資料を 2 つの層に分けることです。

一次資料：公式ドキュメント、公式ブログ、公式仕様
「事実レイヤー」と「仕組みレイヤー」を定義するために使う。
二次資料：個人講演、経験共有、第三者による解説
「語り方レイヤー」「事例レイヤー」「視点レイヤー」「論点」を補うために使う。

つまり、次のように考えます。

原理、定義、トリガータイミングは、OpenAI / Anthropic / MCP の公式資料を優先して引用する
事例、経験、テーマ設定の角度、共有の流れは、以下の二次資料を引用してよい
二次資料の中に強い事実判断が出てきた場合は、本文に入れる前に一次資料へ戻って確認するのが望ましい

Geoffrey Challen「A Day With Claude: Using and Teaching Coding Agents」

リンク：Geoffrey Challen「A Day With Claude: Using and Teaching Coding Agents」
置くのに適した場所： Agentic Coding とは何か、チームの働き方はどう変わるか、教育と組織はどう適応するか
引用に適したポイント：この資料は、完成度の高い keynote のような構成になっています。単にツールを紹介するのではなく、「Plan -> approve -> agent が実装 -> テストで検証する」という新しい働き方を、一本のストーリーラインとして語っています。
参考にできる内容：
- いきなり定義を積み上げるのではなく、「ある 1 日のワークフロー」で agentic coding を語る
- 「実装を反復する」から「計画を反復する」への変化を強調する
- テストは付属品ではなく、agent loop の secret weapon だと強調する
- 組織と教育システムは、この新しい働き方に適応する必要があると強調する
文書に取り込む際の提案：この資料は「トレンドと働き方の変化」の章に、経験事例として置くのがより適しています。彼個人の利用データを、そのまま業界全体の一般結論として扱うべきではありません。

Claude Code Anonymous「Agentic Coding: Real Talk from the Trenches」

リンク：Claude Code Anonymous「Agentic Coding: Real Talk from the Trenches」
置くのに適した場所： テーマ角度ライブラリ、よくある誤解、経験型共有の素材
引用に適したポイント：これは 1 本の資料というより、presentation collection 全体です。主な価値は「権威ある結論を 1 つ与えてくれる」ことではなく、「他の人たちがどの角度から agentic coding を語っているか」を見つける助けになる点にあります。
参考にできる内容：
- タイトルの見せ方
- 経験型 talk の切り口
- どの話題が共感を呼びやすいか
- どの概念を単独の 1 ページとして切り出しやすいか
文書に取り込む際の提案：本文中で大量に引用する必要はありません。別途「共有テーマの参考プール」のような小節を作り、今後素材を整理する際のインスピレーション源として使うのがよいでしょう。

Mitsuhiko「Agentic Coding: The Future of Software Development with Agents」

リンク：Mitsuhiko「Agentic Coding: The Future of Software Development with Agents」
置くのに適した場所： 概要部分、なぜ agentic coding が急に立ち上がったのか、ツール全体像
引用に適したポイント：この資料は、全体像を示す視点として非常に適しています。agentic coding の定義が比較的明確であり、ツール、workflow、observability、context conservation についてもはっきり議論しています。
参考にできる内容：
- agentic coding を「AI が単にコードを提案するだけでなく、planning / implementing / refining に参加するソフトウェア開発プロセス」と定義する
- ツールと workflow の設計原則を強調する
- 「MCP が多すぎると context rot がより早く起きる」と明確に指摘し、coding agents では MCP を慎重に使うべきだと提案している
文書に取り込む際の提案：この資料は、現在の「Skill 優先、MCP は補助」という論証を強化するのに非常に適しています。公式仕様ではありませんが、実戦的な観点から強い裏付けを提供してくれます。

hiromitsusasaki「The World Has Changed」

リンク：hiromitsusasaki「The World Has Changed」
置くのに適した場所： 業界全体像、Plan モード / Spec-driven development、エコシステムの変化
引用に適したポイント：この資料は非常に新しく、今回話したい方向性にもかなり近いものです。spec-driven development、Plan モードの普及、Kiro / Claude Code / Copilot / Cursor などのエコシステム変化をつなげて整理しています。
参考にできる内容：
- 「先に plan、後で coding」が主流のインタラクションモードになりつつある
- spec-driven development は agentic coding の上位方法論として位置づけられる
- ツールエコシステムは、単一の補完機能から「複数ツールの併存 + ワークフローの階層化」の段階に入っている
文書に取り込む際の提案：「なぜ今急に盛り上がっているのか」と「働き方はどう変わりつつあるのか」の 2 節に置くのに非常に適しており、視点を一段高くする助けになります。

Gota「CodexでもAgent Skillsを使いたい」

リンク：Gota「CodexでもAgent Skillsを使いたい」
置くのに適した場所： Skill vs MCP、Skill の考え方を Codex にどう移植するか、コンテキストエンジニアリング
引用に適したポイント：この資料は、私たちの文書の現在の主線と非常に高い一致度があります。明確に次の点を扱っています。
- MCP server の読み込みはかなりの token を消費する
- MCP をつなぎすぎると、ツール選択の精度が下がる
- Skill は階層的に読み込める
- AGENTS.md を使うことで、Codex にスキルを認識させ、自律的に選択させることができる
参考にできる内容：
- L1 メタデータ / L2 SKILL.md / L3 スクリプトという構造で Skill を説明する
- なぜ coding agent には、MCP を無制限に積み上げるよりも Bash / Shell + Skill のほうが向いているのかを説明する
- AGENTS.md が「Codex に選択可能なスキルを知らせる」役割を担えることを説明する
文書に取り込む際の提案：この資料は重点的に吸収すべきです。特に、既存の「Skill が MCP よりチームに適している理由」の節を補強するのに向いています。

Sunagaku『Codexを使い倒して気づいた、Claude Codeの本当の強みと使いこなし術』

リンク：Sunagaku『Codexを使い倒して気づいた、Claude Codeの本当の強みと使いこなし術』
配置に適した場所： 実践テクニック、multi-agent / review agent、ツール比較
引用に適したポイント：この種の資料の最大の価値は、定義を与えることではなく、「実際にどう使いこなすか」をより地に足のついた形で説明する助けになる点です。
参考にできる内容：
- Codex と Claude Code の違いをどう説明するか
- subagent / review agent のような実践的な使い方をどう説明するか
- 経験を「そのまま真似できる」workflow としてどう整理するか
文書に取り込む際の提案：前半の原理章よりも、後半の「使い方のコツ / 実践経験」部分に置くほうが適しています。

PromptLayer『Watch my AI Engineering talk: How Claude Code Works』

リンク：PromptLayer『Watch my AI Engineering talk: How Claude Code Works』
配置に適した場所： agent loop の原理、なぜ Bash が重要なのか、なぜ subagent が有効なのか
引用に適したポイント：これはより「原理の分解」に寄った資料です。特に吸収する価値があるのは、次の点です：
- CLAUDE.md は本質的に、編集可能な markdown の説明ファイルである
- Bash は coding agent にとって universal adapter である
- subagent の価値は、サブタスクを独立したコンテキストウィンドウに隔離し、メインコンテキストの汚染を避けられる点にある
文書に取り込む際の提案：「Skill / コンテキストエンジニアリング / agent loop」の近くに補足として入れるのに適しています。「なぜシンプルなツールの組み合わせがむしろ有効なのか」を説明するために使えます。

これらの二次資料を、現在の文書とどう接続するか

次のように導入することをおすすめします：

「Agentic Coding とは何か」に Geoffrey と Mitsuhiko を補う
全体像と働き方の変化に関する叙述を強化するためです。
「Skill / MCP / AGENTS.md / CLAUDE.md の原理」に Gota と PromptLayer を補う
Skill の階層的読み込み、Bash、subagent、MCP の限界といった論点を強化するためです。
「なぜ今盛り上がっているのか」と「業界の変化」に hiromitsusasaki を補う
spec-driven development、Plan モード、エコシステムの変化をつなげるためです。
「実践テクニック」または将来の「経験編」に Sunagaku と Claude Code Anonymous を補う
事例、タイトルの切り口、実践経験を豊かにするためです。

現段階での使用原則

現段階では、本文では次の原則を保つことをおすすめします：

仕組み、定義、発火条件：公式情報源を優先する
経験、説明の仕方、実践的な見解：これらの共有資料で補足する
議論の余地がある判断：「プロトコル上の事実」ではなく「実践上の見解」として明示する