はじめに
先日、MCPを自分で作成しながらGitHub Copilot Agentを使ってみたところ、その拡張性の高さに感動してしまいました。（参考：MCP初心者がTROCCOのMCPを作って遊んでみた話）AIコーディングエージェントはほかにもCursor／Cline／Devinなどで多くの活用事例が出てきていますが、記事にもなっている通りエンジニア以外にも使えるものだということも強く感じられました。
とはいえ、エンジニアにせよそれ以外にせよ、このツールを効果的に活用するにはナレッジマネジメントが重要になってきます。これから先、ナレッジマネジメントが上手くできているかによってAIエージェントを活用した生産性は何倍にも何十倍にも変わってくるでしょう。そこで、特定のツールに依存しない、AIエージェント時代のナレッジマネジメントの考え方について自分なりに整理してみようと思います。
こんな方におすすめ
- AIエージェントはどうすれば効果的に活用できるかを考えたい方
- エンジニアではないのでAIコーディングエージェントはちょっと遠い存在だと思っているが、自分の業務で使えないか気になっている方
なお、本記事ではAIコーディングエージェントをベースに整理していますが、考え方の整理が中心なのでエンジニア以外でも参考になると思います。また、エンジニアリングの領域は技術革新の最先端を走っているので、技術的複雑性が隠蔽されたサービスが今後他の領域に展開されてくると想定されますが、それを上手く活用していくためにも役立つかもしれません。
従来型のLLＭからの変化
昨今のAIコーディングエージェントの発展について考える前に、まずは従来の対話型LLMについて簡単に抑えておきましょう。これまでのLLMは、以下のような流れで利用されていました。
まず、学習データとモデルの作成方法をもとに基盤モデルが構築されます。データ量を増やすことで性能が上がっていくことは周知の事実で、OpenAIのモデルは驚くべき速度で性能が向上しています。DeepSeek R1は強化学習をベースにモデルの作成方法を革新したことで、低コストで高性能の基盤モデルを開発したと言われています。
続いて、構築された基盤モデルに、追加のデータを加えて追加学習を行うことができます。例えば、サイバーエージェントはDeepSeek R1に日本語データで追加学習を行い、日本語での返答も可能なモデルを開発／公開しています。
ここまでは比較的技術者向けですが、それほど知識がない人でも調整ができるのはこれ以降の部分で、
- システムプロンプト：プロンプトを実行する際に必ず準拠するよう依頼する指示
- ユーザープロンプト：プロンプトの表現／指示内容を調整することでLLMの返答を調整する
- RAG：基盤モデルは学習に利用されたデータに即した知識しか持たないので、例えば自分のプロンプトに固有なコンテキスト情報や、学習に利用された以降の時期の最新の情報を補足情報としてインプットする
- 過去の対話：多くの対話型LLMで特に指示せずとも連携されることで、過去の対話の内容を既知として返答を調整する
といったものがあります。
そこで、ユーザーとしては、基本的に以下の観点で望んだ返答が得られるかを調整することになっていました。
- どのモデルを利用するか
- いかに追加の情報を与えるか
- スコープを小さく／明確にする＋αでいかにプロンプトを最適化するか
「適したモデルに対して、タスクを小さく切って、十分なコンテキストを与えること」が要点だと言えるでしょう。
AIエージェントがもたらすパラダイムシフト
対話型LLMではどういう依頼をして、どういう返答を得られるかという点に処理が閉じていましたが、AIエージェントになると処理内容が大幅に拡張されるようになります。この背景には、以下のような技術革新があります。
- 学習データの増加による、準拠する知識の増大
- 推論の質が向上したことによる返答の質の向上
- 入力データの量や質（＝マルチモーダル化）の拡大
- タスクの段階を追った処理や、コマンド実行の実現
- 外部システム連携の標準化（MCPやA2A）
こういったことが実現されることで、AI自身が自律的に処理を設計／検討し、実行していくことができるようになってきています。ちなみに、AIコーディングの領域ではこれがわかりやすく発展し、以下のように機能拡張してきています。
- 入力されるコードの予測機能
- 既存のコードの解説／レビュー／修正提案機能
- 指示に応じたコードの生成／修正機能
- コードの実行／テストを踏まえた動くコードの生成
Slackで指示を出せば勝手にコードを生成して変更提案を行ってくれるDevinというツールは革新的で、多くの企業で導入されてきています。また、Devinの開発企業がGitHubのリポジトリをもとに解説のドキュメントを自動作成してくれるDeepWikiというサービスを提供しているのですが、自分で作ったMCPのリポジトリを読ませてみたら超高品質で泣きました。
さて、このとき、コードを書くだけでなくコマンドの実行が行えることで、コーディングエージェントはコーディング以外のタスクにも活用できるようになっています。Devin観察日記のシリーズは非常に面白く、飲み会でのモバイルオーダーやフードデリバリーの注文さえもできています（すごい）。
AIエージェントは自律的に動いていくことができるので、様々な業務を劇的に変革する可能性を持っています。一方で、AIエージェントを適切に動かすにはAIエージェントが動きやすい環境を整備する必要があります。
AIエージェント活用に向けた検討観点
では、AIエージェントを効果的に活用するにはどのような環境を整備すればいいのでしょうか。その具体的な内容について考えを整理していきます。
基本的な考え方
まず、前提となる人間の性質について抑えておきましょう。人間は根本的に面倒くさがりな性質を持っています。そこで、
- インターフェイスのスイッチングを極力避ける方が活用が進む
- あのときはこれ、このときはこれという形にインターフェイスが変わると、使う人が限定される
- いちいちレビューが必要になると、人間がボトルネックになる
- なるべくAI側の実行を制約しないようにしつつ、セキュリティ的にはガードレールを設ける
- 一方で、AIが変な行動をしないようにコントロールする必要がある
- 実行が適切な行動を行えるように、指示内容を制御する
といったことが必要になります。
また、上手く使うときのコツは対話型LLMの時代から変わっておらず、「適したモデルに対して、タスクを小さく切って、十分なコンテキストを与えること」です。
モデルの選択については、ツールの選択（GitHub Copilot／Cursor／Cline／Devin）、モードの選択（Ask = 対話型／Agent = 自律駆動など）、モデル（GPT 4o／Claude 3.5 Sonnet／Gemini 2.0 Flashなど）が対応するものになっています。
ツールの特性の違いについては、GitHub Copilot Agentはないですが以下の記事でまとまっています。
次の記事ではCursorとDevinの違いについて整理されています。
さて、タスクとコンテキストについては、タスクの一般性⇔特殊性と複雑⇔単純のマトリクスをもとにAIに委ねるタスクを整理しつつ、
- 設計フェーズと実行フェーズを切り分ける
- 前提条件を適切に読ませる
- タスクを的確に分解する
- タスクを実行する
といったポイントは引き続き重要です。
一方で、新たに重要になってくるのが、AIがフィードバックループを回す補助をしてくれること、そしてさらにはAI自身がフィードバックループを回す主体になるという点です。
これは、対話型に閉じない処理ができることで、AIが実行結果を永続化して残すことができることに起因しています。そこで、
- どの情報をどこに持たせるのか
- 実行結果をどのように永続化させるか
- そのためにどのように外部サービスと連携させるか
といったナレッジマネジメントの重要性が上がってきます。
AI-Poweredなフィードバックループの構築
この部分については、YouTubeの質疑のまとめを作成するデモを実施していた以下のイベントに着想を得て考えを整理しています。めちゃくちゃ勉強になったので、興味があればアーカイブ動画を見てみてください。
さて、AIがフィードバックループを回す補助をしてくれるとは、どういうことでしょうか。流れとしては以下のようなイメージになります。
つまり、
- 初期の計画の作成にあたって、手順を整理したドキュメントを改善していく
- 実行結果をもとに実行ドキュメントに結果を記録する
- インストラクション／ナレッジをタスクを実行する度に改善していく
- タスク全体の完了後に一般的な知識としてインストラクション／ナレッジを改善していく
といった内容になります。
VSCodeのGitHub Copilot Agentを例にして紹介します。システムプロンプトとしてはVSCodeのsettings.jsonに以下のような設定があり、対応するファイルに指示を記載しておくことで、コード生成／テスト生成／レビュー／コミットメッセージ実行時の処理方法を仕込んでおくことができます。
{
"github.copilot.chat.codeGeneration.useInstructionFiles": true,
"github.copilot.chat.codeGeneration.instructions": [
{
"file": "copilot-instructions-codeGeneration.md"
},
],
"github.copilot.chat.testGeneration.instructions": [
{
"file": "copilot-instructions-testGeneration.md"
},
],
"github.copilot.chat.reviewSelection.instructions": [
{
"file": "copilot-instructions-reviewSelection.md"
},
],
"github.copilot.chat.commitMessageGeneration.instructions": [
{
"file": "copilot-instructions-commitMessageGeneration.md"
},
],
}
ワークスペースレベルでは.github/copilot-instructions.mdのファイルに記載された内容を、あらゆる処理の実行前にまず確認するようになっています。最後に、個別のプロンプトとしては.prompt.mdのファイルをもとに実行するよう指示すると、その記載内容に則って実行をしてくれます。
このとき、これらの設定ファイルはワークスペース内に存在するので、AIエージェントから作成／更新をかけることができます。実行指示／制御をテキストファイルとして残しながらアップデートしていくことで、AIを使った処理内容の磨き込みが自然とできるようになるのです。
ちなみにCursorなど別のツールでも同様で、その例として以下の記事が参考になりました。
また、AIを使ったワークフローのようなものも、Difyといったサービスで簡単に実装できるようになっています。そこでまずはコーディングエージェントを使いながら手元の実行内容を洗練させていき、ある程度完成度が高くなったものをワークフローにして定期実行／アプリ化するみたいなことも広がっていくでしょう。もちろん最初からDifyでプロトタイプを作ることも効果的です。
AIエージェントのためのナレッジマネジメント
フィードバックループを効果的に回す／フィードバックを加速させるためには、ナレッジマネジメントが重要になります。ここからは、いくつかデータの流れのデザインパターンを取り上げることで、考えを整理していきます。
この部分については、以下の記事に大変な影響を受けました。ぜひ読んでみてください。
ナレッジ活用のデザインパターン
ナレッジ活用のデザインパターンとして、
- 情報取得
- フィードバックループ
の2つの観点から考えてみましょう。
単純な情報取得
ナレッジ活用の最も基本的な形は、ユーザーの作成／更新したローカルドキュメントをエージェントに読み込ませる以下のような形です。
上に加えて、外部データとの連携を考えると、以下のような形が考えられます。
ここでは、
- エージェントが直接外部ソースを参照する
- 何らかのソースからローカルに連携されたドキュメントを参照する
- MCPやナレッジエージェントを介して外部にアクセスしながら情報を取得する
ような形が考えられるでしょう。
なお、ナレッジエージェントととは私の勝手な造語で、A2Aつまりエージェントとエージェントが連携していくことを考えたときに、ナレッジの取得に特化したようなエージェントと連携して情報取得をすることもあるだろうと思って記載しています。
フィードバックループの構築
先述した単純な情報取得のパターンは、AIエージェントを動かす上での基盤となるでしょう。しかし、ナレッジに対していかにフィードバックループを適用させていくかがAIエージェントの活用では重要になってきます。
そこで、まずはユーザーとエージェントのシンプルな関係を考えます。この形では、ローカルドキュメントはユーザーが作成／更新するだけでなく、エージェントも作成／更新をしつつ情報取得する形になっています。
外部の情報を参照しようとすると以下のような形になります。
このとき、更新元が増えることになるので、いかにドキュメントを同期していくかがポイントになります。
直近話題になっているObsidianの活用は、これを実現するための1つの解です。それぞれをgitを通して自動同期しつつ、エディタのワークスペース機能で開発フォルダとドキュメントを同期したフォルダを仮想統合することで、ドキュメントの参照／更新と活用を実現しています。
なお、このときコンフリクト（編集の競合）の発生リスクが生じるので、これを防ぐための運用整備が必要になります。私もこれを書いている途中に記事が消去されました（笑）
ObsidianでのGit連携については、以下の記事を参考にしてください。
マルチデバイスにただ連携すると、デバイス固有のデータでコンフリクトが無限に起きるので、.gitignoreに除外設定を入れるのを忘れないようにしましょう。
次に、同期がややこしいならクラウドサービスをベースにして、そこに一元化するという方法も取れます。GitHubをベースにするのはその実現方法の1つです。
以下の記事では、タスクを分割してIssueを作成するような形で利用しています。
似たような事例として、Issue作成をDevinに任せるようなものもあります。
また、MCPを介してConfluenceを活用するような事例も出てきました。
以上、ここで整理したのは設計方法の一部でしかありませんが、少なくともドキュメントとコーディングのフィードバックループが回りやすくなることで、設計と実装が同一のインターフェイスで実施できることのメリットは大きく、環境整備を考えていくときのベースとなるでしょう。
ナレッジの整理とデータ化
フィードバックループやナレッジマネジメントを機能させるには、ナレッジの整理とデータ化が求められます。AIを利用することで整理は促進されますが、それを上手く組織的に整備／展開していくことは重要です。
- ナレッジの階層
- 組織レベルの抽象的なナレッジ
- プロジェクトレベルの方針としてのナレッジ
- 個人レベルのTipsとしてのナレッジ
- タイプ
- Stockとして整理されたナレッジ
- Flowとして蓄積されていくナレッジ
また、いかにデータを保持するかというのも重要な観点です。最近のNotionの保持するブロック構造がAIと相性が悪いのではという記事が気になりましたが、エンジニアリングに近いところではYAML、Markdown、HTMLあたりのデータは多く出てくるでしょうし、ビジネスとして基盤になっているWord／Excel／Power Pointのようなデータを、そもそも使わないように進めていくのか、変換して保持するのかは検討観点になりそうです。
また、今回の話はコーディングエージェントがベースなため、何らかのエディタでの業務が発生する場合を前提としています。業務プラットフォーム（Microsoft 365やGoogle Workspace）のみで完結する場合は、データとしてはサービスにロックインされながら、プラットフォーム内での活用に注力することも選択肢になりそうです。
セキュリティを担保するAIの実行制御
ここまでナレッジ周りについて整理してきました。最後に、関連する論点としてMCPを含めたセキュリティの担保についても簡単にまとめておきます。
まずMCPについて簡単に説明しておきます。MCPとはModel Context Protocolの略で、AIエージェントが外部のリソースに働きかけるための処理を規定したものです。
- 外部ツールのAPIを隠蔽しているものが多く、外部ツールへの実行を制御している
- 複数のtoolを登録できるようになっており、1つ1つのtoolに定義された処理がある
- 外部のAPIを使うときは認証情報を登録する形になっている
なお、以下の記事が詳しくかつわかりやすくまとまっています。
これを踏まえると、適切に制御するには、
- APIにアクセスする際のアクセストークンを最小限の権限で発行する
- tool単位で利用可能なものを適切に選択する
- 実行時に個別に実行許可を管理する
- コンテナを利用するなどして、実行環境を自身の環境から切り離す
のように多層的に管理していくことが重要になります。直近多く活用されているサービスの実行環境としては、
- GitHub Copilot／Cursor／Cline：ローカル開発環境
- Devin：クラウド環境
となっています。なお、DevContainerを利用することで、ローカルに設置したコンテナを利用することもできるので、これも選択肢の1つになるでしょう。
また、MCPからの通信をどう制御するかは、今ホットになっているトピックです。そして多くの人が利用しようとすると、トークンの発行が多く行われることになるので、それを適切に管理できるかは非常に悩ましくなりそうです・・・
加えて、以前に整理したパターンのうち、ナレッジをローカルに連携してくる形ではAIが機密情報に触れるリスクが増えてきます。
不必要な機密情報をドキュメントに書かないでくれということは、ちゃんと組織的に徹底していないと容易ではないことです。とはいえAIは一定の確率でやらかしが発生するので、うっかりやらかしてしまったリカバリで泣かないように気を付けましょう。あるいは、そもそも元サービスで一定の権限管理をしていたドキュメントが、外部に連携したときに適切に権限管理されるのかという話も・・・
なお、セキュリティとは別ですが、うっかりファイルを削除するなどはあるあるなので、Gitベースでこまめにバージョン管理をしておくことは必須になります。まだエンジニア向けっぽい小難しいことはまだ多いですが、すぐに何らかの解決策は出てくるような気もします。
さいごに
ここまで、AIエージェントを活用するためのナレッジマネジメントについてまとめてきました。AIが進化した今は、業務にAIを組み込むためのパラダイムシフトが起きています。
フィードバックループの構築とナレッジマネジメントをベースに、力にできれば生産性が劇的に変わっていきます。AIの持つ確率的な挙動を前提に、よりアジャイルに業務を進めていく姿勢が重要になってきそうです。
どこにナレッジを持って、どのようにナレッジを整備／活用していくかは、組織的な推進力が必要になってきます。局所最適を避けながら、事業の性質を踏まえてレバレッジがかかるところに適切に投資していくことが求められるのでしょう。
おまけ：AIエージェントの持続可能性
AIエージェントにベットせよというのはめちゃくちゃ思うし、ワクワクするものですが、一方でこの状態が持続可能かというとそれには疑問もあります。
生成AIは完全に投資フェーズなので事業的に持続可能な形ではないですし、これがインターネットにもたらす影響も気になるところです。
具体的には、以下のようなものです。
- 広告モデルはフリーなインターネットの基盤になってきたわけですが、AIがアクセスするインターネットでは広告が見られなくなる
- だからこそ、AIに情報をどこまで見せるのかという論点がある
- AIの活用は大量の電力を消費するものである
2点目の話として、この記事は非常に興味深かったです。
IT業界にいるものとして今ここにかけないという選択はできないというのは思いつつ、ずっと都合よく使い続けられるものではないだろうし、どう色々なものと折り合いをつけていくのかは考えていきたいですね。
参考記事