申請フォームを開いた状態で、チャットにフォームに何を入れたいのかを指示します。

AI は、あなたが過去に出した申請や、今日の日付、それまでの会話の内容を手がかりに、埋められる項目を探します。そしていきなり画面に書き込むことはしません。

　まず「こう入れようと思いますが、どうですか」という提案カードを出します。

内容を見て「承認する」を押すと、初めてフォームに値が入ります。違うと思えば「取り消し」それだけで反映ができます。

そして、決め手がない項目はユーザーに問いかけをします。たとえば必須項目で、過去の申請からも今日の日付からも決めようがないものは、提案の中に含めず、チャットで聞き返します。

このように、指示・相談をすることで申請内容を提案してくれます。

※領収書の画像や PDF を添付して、「この内容で申請して」と頼むこともできます。

開発を始めるとき、機能の中身より先に決めたことがあります。AI にやらせないことを、先に決める、という作業です。

ワークフローは「申請が通るか、通らないか」に直結します。雑談用のチャットボットが多少ずれた返事をするのとは、間違いの重みが違います。金額が一桁違ったまま承認まで流れてしまえば、それは実害です。

そこで、次の 3 つを設計上の約束にしました。

AI ができるのは提案までです。

　値がフォームに入るのは、人が承認ボタンを押したときだけ。そして保存されるのは、そのあと人が経路を進めたときだけです。

これは Human-in-the-loop（ヒューマン・イン・ザ・ループ） と呼ばれる考え方です。AI の処理の輪の中に、必ず人の判断を一つ挟む。AI が最後まで自走して結果だけ報告するのではなく、決定の手前で必ず人に渡すという設計です。

裏側の作りとしても、AI 側から書き込みを行う経路そのものを用意していません。値の反映は、あなたが手で入力したときとまったく同じ社内の経路を通ります。「AI 専用の抜け道」を作らなかった、と言い換えてもいいかもしれません。

Human-in-the-loop は、しばしば「AI を信用していないから人が確認する」という消極的な仕組みだと受け取られます。

　しかし、私たちの意図は少し違います。人が確認する前提だからこそ、AI に思い切った提案をさせられる。承認という関門があるおかげで、AI は「間違えるかもしれないが、たぶんこれだろう」を提示できます。関門が無ければ、確実なことしか言えない機能になっていたはずです。

選択肢のある項目（リスト、ラジオボタン、チェックボックス）については、今その画面に実際に表示されている選択肢の中からしか値を提案しません。

これは「そう振る舞ってほしい」というお願いではなく、後述する仕組みで機械的に保証しています。

AI が手がかりにする過去の申請は、あなた自身が申請したものだけです。他の人の申請は、AI からは参照できないようになっています。

これは AI への指示で制御しているのではなく、データを取り出す段階で「本人のものだけ」に絞り込んでいます。指示の書き方によらず、他人の申請は出てきません。

ここからが、この機能で一番手間をかけた部分です。

大規模言語モデル（LLM）には、存在しないものを、いかにもありそうな顔で出力するという性質があります。よく知られた話ですが、業務フォームの入力においては、これが特有の形で現れます。

たとえば勘定科目の選択肢が「旅費交通費 / 会議費 / 消耗品費」の 3 つしかない画面で、AI が「出張旅費」というそれらしいが存在しない選択肢を答えてしまう、というような形です。人間なら選ぼうとしても選べないものを、AI は文字列として書けてしまいます。

「選択肢の中から選んでください」とプロンプト（AI への指示文）に書けば、多くの場合はその通りに動きます。

私たちの製品が必要としているのは「多くの場合」ではなく、確実な選択肢を提案することです。そこで、お願いをやめて、仕組みで塞ぐ方針に切り替えました。

AIが考えた提案内容が、そのまま直接画面に表示されるわけではありません。おかしなデータが入り込まないように、途中に「3つのフィルター」を用意しました。

それぞれ役割が全く違うので、少しわかりやすく解説します。

まず最初に、「ちゃんと画面の選択肢から選んでね」「日付はこの形式にしてね」とAIに指示（プロンプト）を出します。

実はこれ、絶対の安全装置ではありません。AIは時々指示を無視するからです。ではなぜ指示するのか？

理由は、後で「その値はダメ！」と突き返してやり直させる回数を減らすためです。やり直しが発生すると、その分AIが考える「待ち時間」も「コスト（APIの費用）」も増えてしまいます。つまり、このフィルターは「なるべく一発で正解を出させて、サクサク動かすため」の工夫です。

AIに自由に文章を書かせると、「理由はですね……」などと余計なことを話し始めたり、回答の形式（プログラムが読み取るためのJSON形式など）が崩れたりすることがよくあります。データが崩れると、システムは読み取ることができずエラーになってしまいます。

そこで、AIが回答できる「型（フォーマット）」を固定しました。専用の「提出箱」を用意して、そこに「項目名」「値」「理由」だけをカチッと入れさせるイメージです。これで、システムが読み取れずに失敗する事態を防ぎます。

ここが一番重要で、絶対にあり得ない値をシャットアウトする「最後の砦」です。

AIから出てきた値が、「今、実際の画面に表示されている選択肢」と完全に一致するかどうかを、システムが機械的にチェックします。もし1文字でも違っていたり、存在しない選択肢を作っていたりしたら、AIがどんなにそれらしい理由を語っても問答無用で捨てます。ここにAIの意志は介入できません。

また、値だけでなく「項目名」もチェックします。もしAIが「備考欄に入れました！」と言ってきても、そもそもその申請フォームに備考欄が存在しなければ、その提案は無効になります。

設計当初は、AI側にも「このフォームにはこんな選択肢があるよ」というマスタデータを持たせておき、AI自身に考えさせようかとも思いました。しかし、それだとフォームの設定が変わった瞬間に「画面の選択肢」と「AIが知っている選択肢」にズレが生じてしまいます。

そこで、「今、目の前の画面に出ている選択肢そのもの」を正解として照らし合わせる方式にしました。これが一番シンプルで確実な方法だったのです。

ここまで読んで、「ずいぶん AI に自由を与えていないな」と思われたかもしれません。実際その通りです。

AI エージェントの作り方については、すでに公開されている設計指針がいくつかあります。私たちはその中から、「確実性を上げる方向」の考え方を重きをおいて採り入れました。主に参考にしたのは次の 2 つです。

Anthropic（Claude の開発元）が公開している、エージェント設計の解説です。この文書はまず、「エージェント的なシステム」を 2 つに区別します。

Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.

（拙訳）ワークフローとは、LLM とツールが、あらかじめ定義されたコードの道筋に沿って組み立てられているシステムである。一方エージェントとは、LLM が自分の処理とツールの使い方を動的に決め、どうやってタスクを達成するかの主導権を保っているシステムである。

そして、複雑さについてはこう述べています。

When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all.

（拙訳）LLM を使うアプリケーションを作るときは、可能な限り単純な解決策を見つけ、必要なときにだけ複雑さを増やすことを推奨する。それは「エージェント的なシステムをまったく作らない」という結論になることもある。

ここから採ったのは主に 3 つの考え方でした。

1. ワークフローとエージェントを区別し、混成でよいと考える

先に引いた区別に沿えば、この機能は意図的な混成です。境界を次のように引いています。

線引きの基準は単純です。業務データの正しさに直結する処理を、確率的な判断に置かない。逆に「前回はどう入力したか」「この領収書は何の費用か」といった、ルールで書こうとするとかえって脆くなる判断だけを AI に渡しています。

2. Evaluator-optimizer（生成 → 評価 → 改善のループ）

原典はこのワークフローをこう定義しています。

In the evaluator-optimizer workflow, one LLM call generates a response while another provides evaluation and feedback in a loop.

（拙訳）評価者・最適化者のワークフローでは、一方の LLM 呼び出しが応答を生成し、もう一方が評価とフィードバックをループの中で提供する。

注目してほしいのは、原典では評価する側も LLM であるという点です。私たちが借りたのはこのループの形だけで、評価役はコードに置き換えました。「弾いて、理由を返して、書き直させる」がそれにあたります。

最近は「AI の出力を別の AI に採点させる」手法もよく使われますが、採りませんでした。

理由は大きく２つあります。

 １つ目に、この機能には機械的な正解が存在するからです。「画面に出ている選択肢と一致するか」は、文字列を比べれば確実に判定できます。わざわざ確率的な判定器を挟む必要がありません。

 ２つ目にこれが一番大きいのですが説明できるからです。「この値は選択肢に無かったので採用しませんでした」と、根拠付きで人に説明できます。評価役が AI だと、「なぜ弾かれたのか」に対して「AI がそう判断したから」としか言えません。

なお「外部の道具で出力を検証させ、その結果をもとに直させる」という形そのものは、研究の世界でも CRITIC という枠組みとして提案されています（ICLR 2024）。人が検索エンジンで裏を取ったり、コードを実行して間違いを見つけたりするのと同じことを LLM にやらせる、という発想です。私たちの場合、その「外部の道具」が業務データそのものだった、という違いになります。

3. 要所で、人のフィードバックのために止まる

この文書は、エージェントの動きを説明する中でこう述べています。

Agents can then pause for human feedback at checkpoints or when encountering blockers.

（拙訳）エージェントは、区切りとなる地点や、行き詰まった場面で、人のフィードバックを得るために処理を止めることができる。

先ほどの Human-in-the-loop がこれにあたり、この機能では提案カードがその地点です。なお原典は、これを「Human checkpoint」といった名前のパターンとして定義しているのではなく、エージェントの動作の説明として述べています。

そしてこの文書は、土台となる Augmented LLM から始めて、5 つのワークフロー（Prompt chaining / Routing / Parallelization / Orchestrator-workers / Evaluator-optimizer）、そして自律的に動くエージェントへと順に説明したうえで、最後にこう繰り返します。

To repeat: you should consider adding complexity only when it demonstrably improves outcomes.

（拙訳）繰り返すが、複雑さを足すのは、それが成果を明らかに改善するときだけにすべきである。

複数の案を並列に生成して多数決を取る、AI にまず計画を立てさせる、複数の AI に分業させるといった手法はいずれも採用しませんでした。やることは「今開いている 1 枚のフォームを埋める」であって、分解も探索も要らないからです。

もう一つが、12-Factor Agents。本番の顧客に手渡せる品質の LLM アプリケーションを作るには何が必要かを 12 項目に整理した文書です。

著者（HumanLayer の Dex 氏）は、主要なエージェント・フレームワークを一通り試し、AI で優れたものを作っている創業者たちと話したその多くは自分でスタックを組んでいた結果として、こう書いています。

I've been surprised to find that most of the products out there billing themselves as "AI Agents" are not all that agentic. A lot of them are mostly deterministic code, with LLM steps sprinkled in at just the right points to make the experience truly magical.

Agents, at least the good ones, don't follow the "here's your prompt, here's a bag of tools, loop until you hit the goal" pattern. Rather, they are comprised of mostly just software.

（拙訳）「AI エージェント」を謳う製品の多くが、実のところそれほどエージェント的でないことに驚いた。その大半は決定論的なコードであり、ちょうど良い場所に LLM の処理が差し込まれることで、体験が本当に魔法のようになっている。エージェント少なくとも良いエージェントは、「はいプロンプト、はいツール一式、ゴールに着くまでループ」というパターンには従わない。むしろ、そのほとんどはただのソフトウェアで構成されている。

これは批判ではありません。そういう作りのものが、実際に良い体験を生んでいるという観察です。そして著者は、この文書の狙いをこう書いています。

The fastest way I've seen for builders to get good AI software in the hands of customers is to take small, modular concepts from agent building, and incorporate them into their existing product

（拙訳）作り手が良い AI ソフトウェアを顧客の手に届ける最速の道は、エージェント作りから小さくモジュラーな概念を取り出し、それを既存の製品に取り込むことであるというのが、私が見てきた限りの結論だ。

つまり 12 項目は「全部揃えないとエージェントと呼べない」という規格ではなく、必要なものを選んで既存の製品に取り込むための道具立てです。名前の由来である Twelve-Factor App（クラウド上のアプリ開発の指針）と同じ性格の文書です。

ツール呼び出しは、構造化された出力を取り出すだけのもの（factor 4: Tools are just structured outputs）

 この文書は「ツール」という概念を特別扱いしていません。

 AI が決まった形の値を出し、それを受けて普通のコードが動く。それだけだと言い切ります。

 第 2 層でやっているのはまさにこれで、提案を「文章の中に埋め込まれた JSON」ではなく

 専用の提出口の引数として受け取り、そこから先はすべて普通のコードです

人への確認も、ツール呼び出しで行う（factor 7: Contact humans with tool calls）

 AI が人に判断を仰ぐことを、特別な仕掛けではなく通常のツール呼び出しとして扱う考え方です。この機能では、AI が提案を提出する行為がそのまま「人に承認を求める」ことになり、

 提案カードの表示につながります。Human-in-the-loop を例外処理ではなく、通常の流れの一部として組み込んだ形です

賢さを上げる方向の工夫・計画を立てさせる、複数案を探索させる、AI 同士に議論させるというのは、うまくいけば精度が上がります。一方で、失敗の仕方が予測しづらくなるという代償があります。なぜその結論に至ったのかを後から追うのも難しくなります。

申請フォームの入力支援に必要なのは、たまに冴えた提案をすることではありません。毎回同じ手順を踏み、外したときに外したと分かることです。そう考えて、確実性を上げる方向の指針だけを選び取りました。

これらの指針は公開されているものです。私たちがやったのは、そこから業務システムに載せられるものを選び、載せられないものを外す、という取捨選択でした。どれだけ AI に任せたかではなく、どこに AI を置いたかそこにこの機能の設計が現れていると思います。

フォーム入力支援機能を作るうえで、私たちが決めたのは次の 3 つでした。

• AI は保存しない。反映も保存も、人が押したときだけ起きる

• AIは画面に出ている選択肢からしか選べない。これは指示ではなく仕組みで保証する

• 手がかりにする過去の申請は、自分のものだけ

便利さを削ってでも、この 3 つは動かさないことにしました。「たまに間違えるけど便利な機能」より、「間違えたときに、間違えたと分かる機能」の方が、業務では信頼できると考えたからです。

そしてその中心にあるのが、Human-in-the-loop 「最後に決めるのは人」という一点です。AI は提案をする。承認するのはあなたです。

またこれからもユーザーアシスト機能を拡充していく予定ですので、「参照範囲を広げたい」など、本機能のFBをじゃんじゃんお寄せください。

(せしょう)

• Anthropic「Building effective agents」（2024 年 12 月 19 日公開）

• Dex（HumanLayer）「12-Factor Agents — Principles for building reliable LLM applications」

• Zhibin Gou ほか「CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing」（ICLR 2024）