編集部のお薦め記事

「RAGは終わった」は本当か――ロングコンテキストが変えたこと、変えられないこと

「AIでインフラ運用の仕事はなくなる」は本当？　生き残るIT担当者の条件

　多くのエンジニアは、AIエージェントをプラットフォームに組み込むのではなく、単なる「高性能な検索エンジン」として扱っている。障害や設定ミスを無計画にAIへ丸投げし、魔法のような解決策を期待しがちだ。

　しかし、その結果得られるのは一般的な回答にすぎない。一見すると説得力があり役立ちそうに見えても、自社の環境には適合せず、本番環境を壊す恐れがある。

　AIエージェントはコードの記述や複雑な問題の推論が可能だ。一方で、プロンプトだけでは克服できない構造的な弱点がある。それは「学習データによる制約」だ。Claude CodeやGitHub Copilotといった汎用モデルは、公開データのみを学習している。そのため、自社固有の運用ルールを把握していない。具体的には以下の情報を持ち合わせていないのだ。

• 命名規則
• システムの制約事項
• 内部サービスのトポロジー
• 独自に抽象化した定義
• コンプライアンスポリシー
• 過去の意思決定のいきさつ
• 障害報告書（ポストモーテム）
• 運用に必要な仕様を記した手順書

　エンジニアがAIエージェントの回答を修正し、自社システムに適合させるために時間を費やせば、本来の生産性向上は期待できない。CIOやリーダー層がAIツールを評価する際は、このギャップを埋める必要がある。成果が出るかどうかは、どのAIエージェントを選択するかではなく、組織がいかに内部知識をエージェントに提供できるかにかかっている。

AIエージェントにインフラの知識を学習させる方法

　自社のインフラ情報をAIエージェントに提供するには、3つのアプローチがある。

• 1.経験に基づく知識の付与

　熟練のエンジニアが、記憶を頼りにプロンプトへ自社固有の指示を含める方法である。「わが社では……を使っている」といった単純な記述だ。これはエンジニアの記憶が正しい場合にしか機能しない。詳細を間違えたり、新人が必要な情報を知らなかったりすれば、信頼性と拡張性に欠ける手法となる。

• 2.静的なドキュメントの活用

　社内標準を記したMarkdownファイルなどの場所をAIに指定する方法だ。あるいは、会話のたびに内容をコピーして入力する。しかし、これは手動の作業で、情報の更新が追い付かず、すぐに古くなる恐れがある。

　さらに、組織の知識は数枚の書類に収まるものではない。Gitリポジトリ、Notion、Confluence、Slack、Zoomの議事録などに散在している。これらの情報源は重複や矛盾を含んでいる。AIと対話するたびにコピー＆ペーストを繰り返すのは現実的ではない。

• 3.コンテキスト対応のリトリーバルパイプライン

　タスクに必要な情報だけを効率的に提供するには、検索拡張生成（RAG：Retrieval-Augmented Generation）を実装すべきだ。具体的には「取り込み（インジェクション）」と「検索（リトリーバル）」の2つのパイプラインを構築する。

• 取り込みパイプライン：散在する社内ドキュメントを収集し、データ化する。これらはベクトルデータベースに保存・管理される
• 検索パイプライン：エンジニアの問い合わせを「Model Context Protocol（MCP）」サーバへ送る。MCPサーバは問い合わせを数値化（エンベディング）し、ベクトルデータベースから関連データを検索する

　最後に大規模言語モデル（LLM）が、抽出された運用情報と一般知識を組み合わせて回答を生成する。Kubernetesのコントローラーを使えば、この取り込み作業を自動化し、ドキュメントの変更と同期させることが可能だ。多くのインフラチームにとって、Kubernetesは既にワークロードが稼働している場所なので、新たなオーケストレーション層を導入する必要はない。

　ただし、RAGの導入には注意点もある。構成要素が増えるため、インフラが複雑化する。また、データの構造が不適切だと回答の信頼性が下がるため、品質管理が重要となる。古いデータが残ると矛盾した回答を招くため、新しいデータを追加するだけでなく、古いデータを削除する設計が必要だ。

AIエージェントによるセキュリティリスクを防ぐ

　AIエージェントがインフラに深く関わるほど、セキュリティとコンプライアンスの重要性は増す。早期に対処すべき3つの領域がある。

• 権限とアクセス管理

　エージェントは機密データに常にアクセスする。そのため、ミスが起きた際の影響範囲を考慮して、エージェントを特権を持つ従業員と同等に扱うべきだ。例えば、インフラの変更は許可しても、クラウドの請求システムへのアクセスは制限するといった厳格な管理が求められる。また、Pull Requestの作成は認めても、人間の承認なしに本番環境へマージさせるべきではない。

• ガードレール（保護策）

　エージェントができること、できないことを制限する安全策が必要だ。データベースの展開やデータの削除、金銭が絡む処理など、リスクの高い操作には必ず「人間の介在（ヒューマンインザループ）」を条件とすべきである。

• オブザーバビリティー（観測可能性）

　AIの推論は非決定論的で、出力や思考プロセスは予測できない。予期しないツールを呼び出したり、同じ質問に対して異なる回答をしたりすることもある。そのため、エージェントの挙動を監視する体制が必要だ。既存の監視ツールを拡張し、ツールの呼び出し状況や入出力を一元的に把握できるようにすべきだ。これは後付けではなく、必須要件として捉える必要がある。

インフラAIエージェントをスケールさせる際の課題

　運用のスケールにあたってエンジニアが直面する大きな課題が「コンテキストウィンドウの制限」と「コスト」だ。

• コンテキストウィンドウの制限

　エージェントが扱うデータ量が増え、コンテキストウィンドウ（AIが一度に処理できる情報量）に詰め込みすぎると、精度は低下する。情報の網羅性は必ずしも良い結果を生まない。パフォーマンスの悪化やコスト増、さらには不正確な回答を招き、システムが使い物にならなくなる。

　これを防ぐには、MCPサーバとのやりとりごとにコンテキストを完全にリセットすべきだ。MCPを通じて、その時のタスクに必要な最新情報だけを取得する設計にする。

• コスト管理

　複数のAIシステムを同時に動かすと、コストは急速に膨らむ。1つの問い合わせが多段階の推論を引き起こし、大量のトークンを消費するためだ。対策として、リクエストの種類に応じて適切なモデルへ振り分ける「モデルルーティング」が有効だ。

　要約や分類といった単純なタスクには安価なモデルを使い、高度な推論が必要な場合のみ強力で高価なモデルを使用することで、コストを最適化できる。

ITリーダーに向けた指針

　インフラ分野でのAI投資を成功させるために、リーダー層が構築すべきアーキテクチャの要件は以下の通りだ。

• 専門特化した複数のエージェント：1つの巨大なAIではなく、責任範囲を分けた複数のエージェントを運用する
• MCPサーバ：エンジニアが使い慣れたツールに、このサーバを統合する
• システムコンテキスト層：社内知識と運用の指針をAIに提供する仕組みを作る
• ベクトルデータベース：社内リソースをデータ化して蓄積する
• エージェントのメモリ機能：エージェントが自身の経験から学習できるようにする
• ガードレール：本番システムに影響を与える要素を優先し、人間の承認プロセスを組み込む
• 観測可能な体制：システムのパフォーマンスとコストを完全に可視化する