導入：なぜ今、私たちは「AIエージェント」を開発するのか？
近年、生成AIやLLM（大規模言語モデル）の話題といえば、「ChatGPTにコードを書かせたら開発が早くなった」「GitHub Copilotでコーディング効率が上がった」という開発ツール（コード生成）としての使い方が主流です。
しかし、AIの本当の革新性はそこだけではありません。
私たちは、AIを単なる「効率化ツール」として使うだけでなく、 システムの中心（脳）として組み込み、自律的に動かす『AIエージェント』の開発に注力しています。
なぜなら、LLMをシステムに組み込むことで、これまでのプログラミングでは実現が困難だった「柔軟性」を持ったシステムが開発できるからです。
既存のプログラミングにはない「LLMの柔軟性」とは？
一言で言うと、従来のプログラミングが「手順をすべて人間がガチガチに指定する開発」であるのに対し、AIエージェント開発は「ゴール（目的）だけを示して、その場の状況に応じて柔軟に動かす開発」です。
その違いは、システムの「柔軟性」という観点から見ると明らかです。
「空気を読める」という柔軟性
従来のシステム：
「もしユーザーがAと入力したら、Bという処理をする」というルール（If-Thenのロジック）を、エンジニアが事前にすべて想定してソースコードに書く必要がありました。そのため、想定外の表記揺れや曖昧な入力、ノイズ混じりのデータがあると、システムはエラーで止まってしまいます。
LLMを組み込んだシステム：
LLMという「文脈を理解する脳」がパーツとして組み込まれているため、多少の言葉の揺らぎや曖昧な指示であっても、その場の文脈からユーザーの意図を汲み取って柔軟に処理できます。システムが「空気を読める」ようになるのです。
「自ら手段を選ぶ」という柔軟性
従来のシステム：
「ボタンを押す ➔ データベースから探す ➔ 画面に表示する」という処理のステップ（手順）が完全に固定されています。
LLMを組み込んだシステム：
「社内ルールについてユーザーの質問に答える」というゴールを与えると、システムは「今の質問に答えるには、どの社内PDFを検索すべきか」「計算が必要だから、計算ツールを起動しよう」と、自分で判断して外部ツールやAPIを組み合わせて使います。手順そのものを、システム自身が動的に組み立てる柔軟性を持っています。
このように、LLMはこれまでのシステム開発の常識を覆すほどのポテンシャルを秘めています。
しかし、いざこの「柔軟性」を実際のビジネスシステムとして形にしようとすると、教科書には載っていない「情報の壁」が立ちはだかります。
ここからは、私たちが今年開発した2つのデモシステムを例に、「一般のイメージ（理想）」と「開発現場のリアル」のギャップ、そしてそれを乗り越えるための設計思想についてお話しします。
開発現場のリアル：理想と現実のギャップ
【事例1】暗黙知抽出チャットボット
――「会話の履歴を全部渡せば、賢くまとめてくれる」という誤解
ベテラン社員の頭の中にある「言語化しにくいノウハウ（暗黙知）」を、AIとの対話で引き出してドキュメント化する――。
このシステムを開発する際、誰もが最初に思い描くのは次のような理想です。
【一般的なイメージ（理想）】
長い対話を行い、その膨大な会話履歴をすべてAIに放り込んで「じゃあ、いい感じにマニュアルにまとめて！」と頼めば、一発で完璧な成果物が出てくる。
しかし、実際のAIの特性は異なります。
【開発現場のリアル】
膨大な会話履歴をそのまま投入すると、AIは「どの文脈が本当に重要なのか」の判断がつかなくなり、要点がボヤけた精度の低いアウトプットになってしまう。
人間でも、1時間の会議の録音ファイルをそのまま渡されて「議事録作って」と言われたら困ってしまいますよね。AIも全く同じです。情報が多すぎると、脳（コンテキスト）がオーバーフローして迷子になってしまうのです。さらに、履歴をすべてAIに投げ続けると、データ量（トークン数）が爆発し、APIの従量課金コストが跳ね上がるという現実的な問題も発生します。
―― 解決策：AIを迷わせないための「情報のモジュール化」
そこで私たちが取ったアプローチは、具体的なコードの工夫というよりも、「AIに渡す情報をどうコントロールするか」という一段上のレイヤの設計（情報設計）でした。
私たちは、最終成果物を作るAIに対して、長大な会話履歴をそのまま渡すことをやめました。
その代わりに、「会話の途中で、数ターンおきにそれまでの知見を小さな単位で構造化（モジュール化）してストックしていく」という仕組みを取り入れたのです。
最終成果物を作るAIには、その綺麗に整理された「データの要約」だけをインプットします。これにより、AIは迷子になることなく、お財布（コスト）にもAIの脳（精度）にも優しい形で、極めて精度の高いドキュメントを生成できるようになりました。
【事例2】マルチモーダルRAG
――「データを放り込めば、AIが勝手に読んでくれる」という誤解
社内にある膨大なPDFマニュアルや仕様書から、AIが必要な情報を検索して回答を生成する「RAG（検索拡張生成）」。さらにテキストだけでなく、画像や図表もまとめて扱えるようにしたものが、私たちが開発した「マルチモーダルRAG」です。
これも、一般的には次のような手軽なイメージを持たれがちです。
【一般的なイメージ（理想）】
社内の共有フォルダにあるPDFや、図表入りのマニュアルをそのままAIのデータベースに突っ込んでおけば、あとはAIが勝手に読み解いて正しい答えを探してくれる。
しかし、ここにもRAG特有の壁があります。
【開発現場のリアル】
マニュアルをそのまま放り込んだだけでは、AIは「図表やグラフの中にある文字」を読み飛ばしたり、平気で事実とは異なる嘘（ハルシネーション）をついたりして、実務では使い物にならない。
LLMは非常に賢いですが、人間が作った「複雑なレイアウトのPDF」や「入り組んだ表データ」をそのまま完璧に解釈できるわけではありません。フォルダにファイルを突っ込むだけでは、AIはすぐに迷子になってしまうのです。
―― 解決策：AIが迷子にならないための「データ構造化」の設計
この壁を突破するために重要だったのも、やはり「AIに渡す前段階のデータ構造をどう設計するか」という、AIの手前側のエンジニアリングでした。
私たちは、PDFをただテキストとして切り分ける（チャンキングする）のではなく、
- 複雑な「表（テーブル）」や「グラフ」を、AIが最も解釈しやすい表現（マークダウン形式など）に事前にパース・変換する
- 画像データに対しては、何が写っているかの説明文（メタデータ）を付与してインデックスを貼る
といった、徹底的な「データのお膳立て（構造化）」を行いました。
RAGの回答精度を左右する重要な要因の一つは、AIモデルの性能そのものではなく、「AIが迷わないように、いかに綺麗なデータ構造に整えてから渡せるか」という、エンジニアによる前処理の設計思想だったのです。
結論：AIエンジニアの本質は、エージェントたちの「監督（マネージャー）」である
2つのデモシステムの開発を通して、私たちが強く実感したこと。それは、これからのAIエージェント開発におけるエンジニアの役割の本質は、「AIたちの状態を脳内で想像し、緻密に制御すること」だということです。
複数のAI（エージェント）を連携させて一つのシステムを動かすとき、
- それぞれのエージェントに、今どんな役割（キャラクター）が与えられているか
- それぞれが、今どんな情報（記憶や文脈）を持っている状態か
これらをエンジニア側が正確に把握し、状態管理をしてあげなければ、システムは簡単に破綻してしまいます。
これは従来の「ソースコードを一行ずつ書く」という感覚よりも、「複数の部下の状態を把握し、的確な指示を出すプロジェクトマネージャー」や「映画の監督」の仕事に非常に近いです。AIという意志を持つ（かのように振る舞う）モジュールを、いかに手の内でコントロールするか。ここにAI時代のエンジニアの、新しい腕の見せ所があります。
AI時代だからこそ、エンジニアの「抽象化・設計力」が最大の武器になる
ここまでお話ししてきた通り、AIエージェント開発の本質は、AIのプロンプトをいじることではありません。
- 膨大な情報から、何が重要かを切り出す（抽象化）
- AIのポテンシャルを最大限引き出すために、役割と記憶をコントロールする（状態管理）
- 複雑な処理を切り分けて、段階的にAIに処理させる（プロセス設計）
これらはすべて、従来のシステム開発で優れたSE（システムエンジニア）がやってきた「設計力」や「データの扱い方」そのものです。
AIという最新技術を扱いながらも、本当に差がつくのは「情報を扱うエンジニアとしての地力」です。
最新の技術を駆使して、これまでにないシステムを創り出す――。そんなエンジニアリングの本質的な楽しさを、私はこの開発を通して再確認しました。