コンテキストエンジニアリング時代の共通規格について

AIの活用方法において、2023年〜2024年頃までは「プロンプト」がキーワードになりがちでした。

一方、2025年頃からは(特に開発文脈で)「コンテキスト」が話題の中心に移っています。

この変化は、AIが「質問に答えるチャット」から「作業を進めるエージェント」へ近づいたことで、課題の焦点が変わってきたことによるものです。つまり、単発の入力文を工夫するよりも、作業に必要な前提・制約・手順・参照情報を、継続的に安定供給する方向性にトレンドが移行した形です。

プロンプトエンジニアリングからコンテキストエンジニアリングへ

プロンプトエンジニアリングは、モデルに渡す「単一の入力文(プロンプト)」を工夫して応答を最適化するアプローチです。よく言われたのが「あなたは〜の専門家です」のような指示で、出力の傾向を変えるといったものです。

一方でコンテキストエンジニアリングは、「モデルが意思決定に使う材料」を設計します。ここで言う材料とは、過去の会話履歴だけではありません。開発文脈であれば、次のようなものが全部コンテキストの対象になります。

  • プロジェクトの前提(アーキテクチャ、依存、命名規約、禁止事項)
  • ビルド/テスト/デプロイの手順
  • 参照すべきドキュメント(設計書、運用手順、FAQ、ADR、ログの読み方)
  • 利用可能なツール(CLI、CI、チケット、外部SaaS、連携プロトコル)
  • チーム/組織のポリシー(セキュリティ、レビュー基準、品質ゲート)

開発では「AIが正しい答えを返す」だけでは不十分で、「AIが正しい手順で、正しい制約のもとで、正しい成果物を出す」ことが求められます。ここで効くのが、プロンプトの言い回しよりも、コンテキスト(前提・制約・根拠)の整備です。

フォーマットの乱立

コンテキストが重要になると問題になるのが「それをどこに、どう書くか」です。

以前は各種ツールごとにフォーマットがあり、それぞれ置いていました(以下は代表例で、現在でも使用可能)

  • GitHub Copilot:リポジトリ共通の指示は .github/copilot-instructions.md、さらにパス別には .github/instructions 配下に NAME.instructions.md を置く、という構成
  • Cursor:プロジェクトルールは .cursor/rules に置き、適用範囲をパターンで絞る(.mdc のフロントマター等で制御できる)
  • Claude Code:プロジェクトの記憶(共有コンテキスト)として CLAUDE.md を置けるほか、.claude/rules の複数ファイルでルールを分割でき、さらにユーザー/組織レベルも含めた階層管理が可能

組織全員が同じツールに統一していない場合や、統一していてもツールを移行する場合に更新が発生してしまいます。

最近では、こうした課題を減らす方向で「複数ツールで使いやすい共通フォーマット」が整備され、同じ組織で違うツールを使っていても、コンテキストを共有しやすくなってきました。その代表例が Agents.md と Agent Skills です。

Agents.mdについて

Agents.md は「エージェント向けのREADME」という位置づけの、シンプルなオープン形式です。

内容は自由な Markdown(実質プレーンテキスト)で、典型的には次のような情報を書きます。

  • プロジェクト概要
  • ビルドおよびテストコマンド
  • コーディング規約(フォーマッタ、Lint、命名、ディレクトリ方針)
  • テスト手順

etc…

あまり大きいナレッジは含めず、シンプルに書くことが多いです。

参考:https://agents.md/

Agent Skillsについて

Agent Skills は「手順・知識・(必要なら)スクリプトを、再利用可能な単位にパッケージ化する」ためのオープン標準です。1つのスキルは通常フォルダ単位で、中心に SKILL.md を置きます。SKILL.md は YAMLフロントマター(name と description など)+本文の指示、という形式です。

典型構造は次の通りです。

  • SKILL.md(必須:スキルの説明と手順)
  • scripts/(任意:実行コード。整形、変換、検証などを“確実に”やらせる)
  • references/(任意:設計書や仕様など、参照用の資料)
  • assets/(任意:テンプレ、サンプルデータなど)

最初から全文をコンテキストに流し込むのではなく、起動時はメタ情報だけを読み、必要になったスキルだけ本文・参照資料を読む、という設計が仕様として明確化されています。

採用状況としても、OpenAI Codex は「Skillsはオープン標準に基づく」と明言しており、共有・配布を前提にしています。

また Cursor も Agent Skills をドキュメントとして扱っており、ツール横断のエコシステムが意識されています。

単なるナレッジ共有に留まらず、再現可能なワークフローを共有できるのも大きなメリットです。

Skillsは現在かなり注目されていて、GitHub上の公開Skillを集約して検索できる マーケットプレイスも存在しています。

エージェントスキルマーケットプレイス

※膨大にあるため悪意のあるリポジトリに注意

今後の展望と予想

個人的な予想として、今後AIのモデル側の性能が上がり続けたとしても、コンテキストの重要性がすぐに陳腐化することはないのではないかと考えています。

短期的な理由としては、人間側の情報提供なしに、AIが「この状況で正しい判断」を下すのはまだ難しいからです。

スタンドアロンアプリのように、AIが必要な情報へ一括でアクセスしやすい環境と、SaaS連携やAPI連携が複雑に絡むアプリケーションを比べると、後者の方がAIの出力品質は落ちやすいです。根拠となる情報が分散し、制約も増え、さらに“何を見に行けばいいか”自体が文脈依存になるためです。これをモデル性能だけで吸収するのは短期的には難しい、と考えています。

中長期的な理由としては、人間が企業を運営していることによる限界がある点です。

言葉の定義の違い、暗黙知、説明責任、インシデント対策のためのガードレールの設計(どこまでやってよいかも絶対的な正解はない)など様々あり、これらは人間側が情報提供していく状況が続くと考えます。

なので、当面はコンテキスト作りを業務のテーマにしていこうと思います。(とはいえ、トレンドがすぐ変わるので、数か月単位での見直しも必要です)

参考:Cursorの5つの指示方法を比較してみた:AGENTS.md、ルール、コマンド、スキル、サブエージェントの使い分け

   https://agentskills.io/home

   https://github.com/anthropics/skills