エージェント組み込みでチャット画面から作るのは遠回りです
画面と承認は業務アプリ側が持ち続けます

「社内チャットボット」の企画書を持っている方へ

在庫管理・受発注・問い合わせ対応などの業務システムにAIを足す検討をしていて、企画書の画面イメージがチャット画面になっている方に向けて書いています。

チャット画面が悪いわけではありません。ただ、業務の生産性を上げる目的なら遠回りです。理由は単純で、業務の文脈は業務画面の中にあり、チャット画面には無いからです。この記事では、2026年8月にOpenAIが公式サンプルとして示した逆方向の設計を、発注仕様に落とせる粒度まで分解します。

人間がAIとシステムの間の接着剤になっていないか

チャット型の導入でよく起きる運用は、こうなります。担当者が業務画面で異常に気づく。対象の伝票番号や履歴をコピーする。チャット画面に貼り付けて状況を説明する。回答を読む。業務画面に戻って自分で入力する。

このとき人間は、AIと業務システムの間でコンテキストを運搬する接着剤になっています。文脈の運搬・プロンプトの作文・結果の転記がすべて人手で、しかもAIが何を見て何を答えたかは業務システム側に記録されません。使う人のプロンプト力で成果が変わるため、組織として品質を揃えることもできません。

逆方向の設計は、エージェントを業務画面の中に入れます。担当者は該当レコードを選んでボタンを押すだけ。文脈はアプリが供給し、結果は画面に返り、記録も残ります。プロンプトを書けない人でも同じ品質で使えることが、業務システムに組み込む最大の価値です。

公式サンプルが示した責任分担

OpenAIは2026年8月19日のブログで、出荷管理ダッシュボードにエージェントを組み込んだサンプルアプリRelayを公開しました。細部より、責任分担の線の引き方が重要です。

同じブログでは、この型を税務業務に適用した事例として、パイロットで7,000件の申告を処理し、準備時間を約3分の1短縮した数字が紹介されています。エンジニアリング以外の業務にも同じ分担が効く、というのが公式の主張です。

線の引き方を一言にすると、アプリが文脈と統制を持ち、ハーネスがループを担う。ハーネスという層が何をするかは入門記事に書いたとおりで、そこは自作せず部品を使います。自社で設計すべきは上の表のアプリ側の4行です。

設計の中心は承認の置き場所です

アプリ側の4行のうち、最初に決めるべきは承認です。

Relayの設計では、照会系の操作はエージェントが自走しますが、出荷の変更のような結果に影響する書き込みは、必ず人間の承認を待ちます。ここで重要なのは、承認が「プロンプトで確認するようお願いする」ことではなく、実行の仕組み側で強制されていることです。エージェントへの指示文はすり抜けられますが、実行側のコードは擦り抜けられません。

つまり組み込み設計の実務は、業務の操作一覧を作り、1つずつ「自走してよいか、承認を挟むか」を仕分ける作業から始まります。この仕分けと権限の絞り方はエージェントに任せる前に権限をコードで絞るで詳しく書いています。

組み込みの技術経路は3つあります

実装の入口は、単発実行のCLI・アプリから呼ぶSDK・製品へ深く組み込むサーバー接続の3段階が用意されており、どの深さで組むかは要件次第です。経路の選び方と各社の方式の違いは稿を改めますが、発注側が仕様で決めるべきは経路そのものより前段、つまり上の責任分担の表です。ここが決まっていれば、経路は開発側が選べます。

着手前のチェックリスト

発注側にとっての意味

エージェント導入の路線を現場で量産するか、基幹業務へ組み込むかに仕分けたとき、組み込む路線の設計図がこの記事の責任分担表です。チャット画面の新設ではなく、いつもの画面にボタンを1つ足すところから要件を書いてください。

既存の業務システムのどこにエージェントを埋め込めるか、操作一覧の仕分けから一緒に整理したい場合は、お問い合わせからご相談ください。画面とデータの棚卸しから入ります。