はじめに
ログラスでエンジニアをしている田村です。
先日こちらの記事で、Cursorにデータ取得と回答生成を簡易的に行わせるプロトタイプを作成したあとAmazon Bedrock Agentsで動作するようにし、更に安定的な動作とトレースが必要になったタイミングでLangChainに移植したプロセスについて書きました。 当時は「AIエージェントが自律的に考え、ツール（SQL）を使いこなし、答えを導き出す」というエージェントの形式を取っていました。CursorやBedrock Agentsと比べると固定的な動作をさせていたものの、それでもデータ取得についてはLLMが必要と判断したらそのデータを取得してくるという形で行っていました。
しかし、そこから数ヶ月。私たちは自律的なエージェントに任せる範囲を限定し、固定的なワークフローとの役割分担をするようにしました。 現在、私たちが検証している機能を支えているのは、「あえて自由度を下げた、固定的なワークフロー」です。
なぜ、私たちは「万能なエージェント」の領域を絞り、「堅実なワークフロー」を選んだのか。そして、その先にある「汎用性」という壁について、今どう考えているかをお伝えします。
1. 「何でもできる」が「何も保証できない」に変わる時
当初、私たちはLangChainを用いて、以下のような構成でプログラムを動作させていました。
この構成の最大の強みは「探索能力」です。「このデータの傾向を教えて」といった曖昧な質問が来ても、Agentが試行錯誤を繰り返して答えを見つけてくれる——はずでした。
しかし、PoCを進め、実際にこの「深掘り調査」をAgentに行わせてみると、期待していた柔軟性が逆に仇となる場面が増えてきました。
私たちが実現したかったのは、「特定の内容について、その内訳や背景を深掘りする」という業務です。 ユースケースを探索する段階ではAIがよしなにデータを取得してくる柔軟さが非常に役に立ちますが、業務として定型化し、網羅的にかつ均質に行いたいとなったとき、Agentの「毎回挙動が変わる」という特性が大きなブロッカーとなりました。
具体的に直面した課題は大きく2つあります。
① データ選択の難易度向上と「迷い」
ユースケースを探索している最中に対象とする探索範囲が広がったことで、参照すべきデータ候補が膨大になりました。
その中から「本当に見るべきデータ」をAIに自律的に選ばせようとすると、必要なデータを見落としたり、逆にノイズとなるデータを拾ってきたりするケースが頻発しました。
例えば、人間であれば「A事業部についてリサーチするなら、このマスターとこのトランザクションデータを見る」と即座に判断できる定型的な処理でも、AIに「考えて選べ」と指示すると、業務レベルのことも考えながらSQLのカラム名の類似性に引っ張られて全く関係のないログテーブルを見に行ったり、不必要なJOINを試みてタイムアウトしたりと、その都度「迷い」が生じてしまったのです。
② 出力の「ムラ」への懸念
定型業務をカバーする際に求められることとして、均質性も重要な要素です。
しかし、Agentのアプローチでは、あるデータについては詳細にドリルダウンして確認するのに、別のデータでは表層的なコメントで終わる、といった質のバラつきが発生してしまいました。
システムプロンプトに「〇〇の場合は必ず××せよ」というルールを詳細に何個も書き連ねることもできますがルールを守ってくれないこともあり、このままプロンプトチューニングを極めることになるのか？と思っていました。
エージェントを複数に分割して回答させることも試しましたが、簡易的に試した範囲では安定性の向上幅の割にレイテンシとコストの上昇幅が大きかったため断念しました。
その頃、Xなどのコミュニティでは自律的・非決定論的なエージェントの不確実性に対する議論が活発になっており、「決定的なワークフローの方が実用的ではないか」という声をよく聞いていました。 弊社CTOの伊藤もこの話題に「決定論的システムと非決定論的AI Agentの接合点」をテーマに記事を公開しています。
回答の品質を安定させたいという課題感と、以前から気になっていたこの潮流を自分たちも試してみたいという思いが重なり、舵を切ることにしました。
2. 技術的ピボット：思考の外部化
そこで私たちは、AIの自由度を下げてワークフロー化することにしました。
業務を「プログラム可能な粒度」まで分解する
単にツールを変えただけではありません。元々人間が頭の中で組み立てて行っている「データの確認」という業務を、誰でも（=プログラムでも）再現できる粒度まで因数分解しました。
「〇〇について内訳とともに詳しく教えて」
エージェントに対するこの指示は、実はあまりにハイコンテキストです。
これをワークフローに落とし込むために、以下のような「固定の手順（レシピ）」を定義しました。
- 対象の特定: 指定された範囲における集計対象の数値を取得する。
- 内訳の確認: その数値を構成する主な項目（内訳）を洗い出し、影響の大きいものを特定する。
- コンテキストの取得: その事象に関連しそうな定性情報や周辺データを検索して紐付ける。
- 詳細確認: 必要であれば、より粒度の細かいデータまでドリルダウンして取得する。
- 統合と要約（LLMの出番）: 集まった定量・定性データを繋ぎ合わせ、自然な文章として出力する。
このように、実際の業務というドメインを人間が理解してプログラムとして翻訳し、再現可能な形に落とし込むことで、定型的な部分にAIのリソースを割かない、非決定的な動作をさせないようにしました。
このように業務を分解してAIに渡すアプローチについては、以下の記事で「コンテキストモデリング」という観点から詳しく述べています。
LLMの役割の変化
こうして手順を固定化した結果、アーキテクチャは以下のように変化しました。
LLMの役割は「データ取得ルートを考えること」から、「用意された定量データと定性データの点と点をつなぎ合わせ、滑らかな日本語にする」という、ラストワンマイルの統合と表現に特化されました。
料理で例えるなら、「冷蔵庫の食材を使って、何か美味しいものを作って」とシェフ（Agent）に頼むのをやめ、「材料の調達と下ごしらえは完璧にやっておいたから、あなたは最後の仕上げと盛り付けだけして」と役割を限定したイメージです。
決定論的なシステムと非決定論的なAIの境界をアーキテクチャとしてどのように構成するか、以下の記事ではより堅牢な設計として「Edge / Shell / Core」の3層アーキテクチャを提案しています。
3. 得られた「安定」と「検証可能性」
この「退化」とも取れる変更によって機能の実用性は向上しました。
-
検証が可能になった
これが最大のメリットです。SQL生成部分がロジックとして固定されたため、この部分は従来の単体テストで動作保証ができるようになりました。
「データがおかしい」ならロジックの修正、「文章がおかしい」ならプロンプトの修正、と問題の切り分けが明確になり、デバッグのしやすさが格段に向上しました。
-
信頼性の担保
数値を扱うAIにとって数字がズレることはなるべく避けたい問題です。
「AIが書いたSQL」ではなく「エンジニアが書いたSQL」を実行することで、データ構造や結果の解釈ともにAIの介在を敢えて減らすことで信頼性を向上させています。
-
PoCの実質的な前進
抽象的な指示で何でもやってくれ、というような分析への対応はできなくなりましたが、その分「目の前の特定の課題」に対しては、実用に耐えうる精度を実現しつつあります。
「汎用的だが精度にムラがある」状態から「この領域なら確実に価値が出る」という一例を示せたことで、実用化へのフェーズへ進めることができました。まずは1つの成功を作ることで他のユースケースへの道筋も見えてきます。
-
UXの改善
出力が安定したことで、データ取得用のプロンプト調整に費やしていた時間を、「言い回しの調整」や「引用元の明示」など、ユーザー体験を向上させる機能の実装に充てられるようになりました。
4. 確実なワークフローで柔軟なエージェントをもう一度作る
とはいえ、これで「めでたしめでたし」ではありません。
固定のワークフローは安定する反面、単体のワークフローでは設定されたもの以外の分析には対応できないからです。
(いつ実現できるかはともかくとして)理想形としては、やはりAIが動的に必要なデータを取得し、ユーザーのあらゆるリクエストに柔軟に答えることかと思います。
最初にエージェントからワークフローをメインにする形に転換した際は、精度は上がったもののどうやって汎用化するのかと悩んでいました。しかし、ワークフローを一度固定のワークフローをしっかり採用してみることで、業務として意味のある単位のワークフローを丸ごとツールとして呼び出すことで柔軟性を取り戻せるのでは？と実感としても持っています。
ただ、そこに至るためにも、今は足元の確実性を積み上げる必要があると思っています。そのまま自由度の高いエージェントに戻すのではなく、ワークフローで実現した確実性を土台にしながら、どうやって再び柔軟性を実現するか。もしくはそもそも汎用化を目指すのが正解なのか。
この問いに対する探索はまだまだこれからです。来年も引き続き、お客様の目の前の業務を効率化できるAIエージェント・ワークフローの開発を進めていきます。
おわりに
「何でもしてくれるAIエージェント」という響きは魅力的です。エンジニアとしても、最新のフレームワークを使って自律的に動くシステムを作る方が、技術的な面白みは強いかもしれません。
しかし、エンタープライズの現場で本当に求められていたのは、時々すごいホームランを打つAIではなく、「毎朝確実に業務を遂行してくれる信頼性」でした。 そのために、あえて自由度を捨て、ドメインの仕様と向き合い、エージェントを解体する——。それは「技術的な後退」のように見えて、実際は「プロダクトとしての大きな前進」だったと感じています。
ログラスでは、技術を使って実際に顧客の課題が解決することに熱狂できる仲間を募集しています。
興味を持っていただいた方は気軽にカジュアル面談にご応募ください！
Discussion