AIエージェントが人間に替わって業務を代行していく流れは、一過性のブームではなく必然的な進化です。今回はその発想を起点に中小企業とりわけ製造業向けにシステムを開発しました。
業務にAIを入れるとき、議論の多くは「どれだけ賢いか？」という問いに向かいます。けれど中小企業のバックオフィス業務で本当に問われたのは、賢さではありません。「間違えたときに止められるか？」「何をしているか見えるか？」「いつでも手作業に戻れるか？」——この3つに答えられないシステムは、どれだけ賢くても現場には導入できません。ここが今回のシステム開発の起点となりました。
この記事は、そのシステムの設計面でのコンセプトについて記したものです。AIエージェントの「自律性」と製造業の現場が求める「安全性」。どうのように両者を成立するのか？今回はその疑問に対する著者の回答となりました。
なお、このシステム（Synaptiqと命名しました）は開発をほぼ完了して、実地検証を待つ段階まで進んでいます。詳しい開発工程の話や核となるコンセプトの詳しい説明は連動する他の記事でおこないます。
「SaaS終焉」議論と、私たちの立ち位置
2024年末、投資家のBill GurleyとBrad Gerstnerによるポッドキャスト「BG2」で、Microsoftのサティア・ナデラCEOが業界を騒がせる未来予想を語りました。要約すると——今日の業務アプリケーション（CRMやERPなど）は、突き詰めれば「CRUDデータベースの上に業務ロジックを重ねたもの」であり、エージェント時代にはその業務ロジックがAIの層へ移っていく。
エージェントは特定のバックエンドを区別せず複数のデータベースを横断して更新するようになり、やがて従来型の業務アプリは「崩壊」しうる——という内容でした。これが開発者を震撼させ「SaaS is dead」という見出しで広まりました。
ナデラ本人の主眼は「アプリが消える」ことより、「業務の判断ロジックが、個々のアプリのUIの中ではなく、データの上を動くAIの層へ移っていく」という重心の移動にあります。実際、この未来予想に当初懐疑的な反応を示したSalesforceのマーク・ベニオフも、自社ではAgentforceというエージェント層の製品に比重を置いています。
立場の違いはあれ、「UIに閉じ込められていたロジックが、データの上で動くエージェントへ移る」というベクトルそのものは業界全体で共有されつつあります。
これは、Web開発で先行した「ヘッドレス（headless）」——表示層（ヘッド）をデータ・ロジック層から切り離す設計思想——の、業務システム版とも言えます。ヘッドレスCMSやヘッドレスコマースが「画面は差し替え可能な皮膚で、本体はデータとロジック」と割り切ったのと同じ発想が、いま業務システムの基幹の領域に来ました。
私たちの立ち位置は明快です。この流れは必然であり、止められない。ならば、中小製造業という現場で「安全に成立する形」に落とし込むことに価値がある、と考えました。承認駆動もヘッドレスも、私たちが奇をてらって選んだのではなく、AIが業務を代行する時代の必然的な帰結として選ばざるを得なかった——この順序が、この記事でいちばん伝えたいことです。
3つのコアコンセプトとシステムの全体像
まず下の図を見てください。これが今回のシステムの全体像を表したものです。
AIがデータを操作して業務をおこない、外部に送信する手前では必ず止まり人間が「承認」だけを行う。この流れを頭に入れて、各概念を読んでください。
ヘッドレス基幹（最小限のUIしか持たない基幹）
従来の業務システムは、人間が操作するための大量の画面を持ちます。入力フォーム、データの一覧、検索機能、マスタ管理——機能が増えるほど画面が増え、覚える操作も権限管理も膨らんでいきます。長い開発期間が必要で、挿入しても定着に時間がかかる。これが従来の業務アプリです。
Synaptiqはこの前提を反転させました。画面を主役にせず、データを主役に置き、そのデータをAIが操作する構成です。私たちはこれを「ヘッドレス基幹（Headless Core）」と呼んでいます。前章のナデラの見立てに引きつければ、業務ロジックをAIの層に置き、AIがデータを直接読み書きする、という形の一つの実装です。
ただし、UIをゼロにことは「まだ」出来ません。AIがおこなった業務は人間が確認して、承認する必要があります。この「判断する・承認する・例外に対応する」部分のためにUIを残します。むしろ最小限に絞るからこそ、その画面は迷いのない、一目で分かるものにできます。
UIが薄くなることによる副次的な効果も大きいです。UIが薄いということは、覚えるべき操作が少なく、権限設計も単純になるということです。人がやることが「承認」に集約されるなら、人を役割で細かく分類する複雑な権限体系は要らなくなる——UIを削ったのと同じ理由で「役割」という概念も削れます。
承認駆動（AIを「優秀な部下」に留める）
ヘッドレス基幹の上で、AIはどう振る舞うべきか？私たちが比喩として用いる表現は「優秀な部下」です。上司でも同僚でもなく、実務をこなし、要所できちんと確認を取りに来る部下。最終的な責任は人間がおこなう——この関係を崩さないことを設計の中心に据えました。
だからユーザーがやることは、原則として「承認」だけです。受注の内容をAIが構造化し、過去の実績をもとに見積の案を作り、人はそれを見て承認するか、限られた範囲を修正するか、差し戻す。私たちはこのコンセプトを「承認駆動（Approval-Driven Operations）」と呼んでいます。
この「優秀な部下」という比喩は、単なる売り文句ではありません。設計判断の指針になります。部下に任せてよいのは実務の部分で、外部に出す書類には必ず上司（人間）の承認が要る——後述する承認ゲートは、この比喩を素直にシステムへと翻訳したものです。
統制つきの自律（能力ではなく制限で安心を作る）
「AIは賢いから任せて大丈夫」という説明を、私たちは意図的に避けました。賢さは安心の根拠になりません。賢いからこそ、想定外のことをしうるからです。現場の経営者が不安に思うのも、まさにそこです。
代わりに私たちが用いるのが「統制つきの自律（Bounded Autonomy）」という考え方です。エージェントはあらかじめ定めたワークフローの範囲内でのみ自律的に動き、レールの外には出ません。安心の根拠は「賢いから」ではなく「決めた範囲しか動かないから」に置く。この線引き——どこを自動で通し、どこで必ず止めるか——を決めることこそが、今回のシステム設計の核のひとつでした。
自律の境界は、3つの要素で定めています。ひとつはワークフロー（どの道筋を通るか？）、ひとつは各ステップでの判断の指示（何をどう判断するか？）、そしてもうひとつが承認ゲート（どこで人に決裁を仰いで止まるか？）です。このうち各ステップの判断の中身は、その会社固有のノウハウの結晶なのでここでは触れませんが、骨格として「道筋・判断・停止点の三つで境界を作る」という構造だけ押さえておいてください。
そして、そのワークフローは汎用のテンプレートではなく、現場の声を聞いて作り込んだものです。では、この境界を——とりわけ各ステップの「判断」を——具体的にどう実現しているのか？次に、コアを支える実装方針を説明します。
支える実装方針 ──コンセプトをどう実現するか？
ここまでの3つが「何を作るか？」だとすれば、ここからは「それをどう実現するか」について説明します。
判断の記述（Codified Judgment）── ここが堀の核心
エージェント型のシステムでは、処理の記述（アルゴリズム）が一か所にありません。ワークフロー（流れの骨格）・各ステップの判断の指示・判断の材料となる参照データ（RAG）——この3か所に分散することになります。そして「判断の中身」を担うのは、後の二つ、すなわち指示と参照データです。
私たちはこの「判断の指示」を、単なるAIへの命令文とは考えていません。その会社固有の判断ロジックを、自然言語で書き起こしたもの——現場でベテランに聞き取った暗黙知を、形式知へ外部化したもの、と捉えています。「この材質でこの数量なら、この段取りで、この工数を見る」といった、長年の勘に近い判断を、言葉として残していく作業です。
ワークフローは、見れば簡単に真似できます。けれど、その会社の判断をどう言葉に起こしたかは、現場を深く理解しなければ書けません。そしてこの判断の記述はバージョン管理し、伴走の中で継続的に改善していきます。ベテランの判断が失われていく事業承継期に、それを会社の資産として残し、育てていく——ここに最大の価値があります。
権限レス（Roleless Access）── 役割ではなく鍵で守る
Synaptiqには「ユーザー権限」という概念がありません。操作の主体はAIで、人は承認しかしない。だとすれば、人を役割で分類する認可レイヤーそのものが要らない——ヘッドレス基幹でUIを捨てたのと同じ理由で、業務ソフトに当たまえに存在したユーザー権限も捨てました。
あるのは認証（パスワードや指紋・パスキー）という「鍵」だけです。役割で人を分けるのではなく、操作の入口に関門を置く。承認も、閲覧も、進捗の確認も、鍵さえあれば誰でもできます。例外とするのは、取引先・品目・単価といったマスタの書き換えだけ。ここには鍵をかけますが、それも「アドミンという役割」ではなく「マスタの鍵を持つ人」という捉え方です。
守りの担保は、入口の「鍵」と、事後の「全処理ログ」の2つ。もっと細かい制御が必要になった場合は、「鍵を増やす」という形で対処して、複雑な権限体系は作りません。シンプルさこそが、安全と保守性の源だからです。
データ中心設計（Data-Centric Architecture）── 疎結合の要
今回のシステムに置いて中心はデータです。画面もワークフローも、互いを直接呼び合うのではなく、すべてこのデータを介して間接的につながります。AIがデータに書き、画面がそれを読み、人が承認してデータを更新して、その更新を受けて後続処理が再開する——という流れです。
この「データを真ん中に置く」設計には明確なメリットがあります。画面とワークフローが直接結合していないので、片方を差し替えても他方が壊れにくい。特定のツールに依存せず、後から一部を載せ替えられる。移行の可能性を確保するうえで、この疎結合は理にかなっています。
顧客名義・データ主権（Customer-Owned Data Sovereignty）
Synaptiqでは、AIのAPIも、インフラ（データベースやホスティング）も、通信（FAX・電話）も、すべて顧客名義・顧客負担で契約します。
理由は明快で、データだけが置き換え不可能な資産だからです。データは顧客の資産として、顧客名義のインフラに、標準的な開ける形で残す。契約でも、アクセス権・エクスポート権・所有権を顧客に帰属させます。
会社が存続する未来でも、承継される未来でも、売却される未来でも、残ったデータは顧客のものになる——事業承継やM&Aの局面では、これがそのまま企業価値の向上につながります。後の章で述べる「自立可能性を約束する」という姿勢は、この実装方針が土台になっています。
チャネル抽象化（Channel Abstraction）
FAX（画像）・メール（文章）・電話（音声）——入口はバラバラでも、AIで構造化して同じ一本の業務フローに合流させます。どのチャネルで受けたかはメタデータとして残します。さらに一枚の注文書の中で、単価のある「確定注文」と、単価が空欄の「要見積」を明細行レベルで振り分けます。両者は一枚に混在することも少なくありません。
このチャネル抽象化の実装は奥が深いので、詳しくは別記事「FAX・電話・メールを同じ業務フローに合流させる」で扱います。ここでは「入口が違っても、合流先の業務フローはひとつ」という設計判断だけ押さえてください。
安心・安全のための設計指針
「何をしでかすかわからないから、AIは使わない。」AIエージェントの実装に携わっていると残念ながらこういった声をよく耳にします。そういった声を払拭するためにSynaptiqには、あらゆる安全設計を盛り込んでいます。
外部に出る出力は、必ず人が承認する
自動化の範囲を考えるうえで、私たちは一本の線を引きました。外部に出る・取り消せない出力は、必ず人の承認を通すという線です。見積、発注、請求、納期回答——相手に届いてしまえば取り消せないものは、AIがどれだけ自信を持っていても、人の承認なしには外へは出しません。
今回、制作したシステムには2つの承認ポイントを置いています。受注を確定する前の「受注承認」、見積を外へ出す前の「見積レビュー」です。逆に言えば、この2点の内側にある処理「データの構造化」は自動で進めてよい、という切り分けです。
止めるべき場所を絞るからこそ、それ以外は滑らかに動かせる。全部で止めれば安全ですが、それでは自動化の意味がありません。全部を通せば速いですが、それでは怖くて任せられない。絞るという判断が重要になってきます。
ここで人間が行えるのは、承認・限られた範囲の修正・差し戻しの三つです。修正が「限られた範囲」なのは意図的で、人が触れてよいのは業務上意味のある特定の項目だけに制限しています。何でも書き換えられる万能の編集画面は、ヘッドレス基幹の思想にも、安全指針にも反するからです。
本体と独立した検査役を置いた理由
承認ゲートに加えて、外部に出る出力の手前にはもう一段、本体とは独立した「検査役エージェント」を常駐させています。実務を進める主体と、それを検査する主体を分ける——いわゆる職務分離です。作った本人がチェックも兼ねると、見落としは構造的に減りません。人間の組織で経理と承認を分けるのと同じ理屈を、AIの中に持ち込んでいます。
この検査役が見るのは、金額の絶対値の大小ではありません。「その取引先・その品目の過去実績から考えて、入力された値が期待からどれだけ外れているか？」という乖離です。高すぎる見積も、安すぎる見積も、どちらも注意の対象になります。「100万円だから危ない」ではなく「この案件でこの額は普段とずれている」を見る、という発想です。
判定の内部ロジックはここでは伏せますが、考え方としては、機械的に全件を素早くさばく層と、リスクの高いものだけ文脈を丁寧に読む層を重ねています。すべてを慎重に見ると遅くなり、すべてを軽く見ると危険。二層のロジックを用いることにより、速度と慎重さを両立させています。
大事なのは、検査役が人の承認を置き換えないことです。検査役はあくまで人間の注意を然るべき場所へ導くだけで、最終判断は人間が下します。AIが二重になっても、責任の所在は動かしません。ここでも「最終責任は人間」という承認駆動の原則が貫かれています。
止められる・見える・戻れる
ここまでの設計を、運用の土台として支えるのが3つの標準装備です。この装備はすべての案件に適用します。派手さはありませんが、現場が安心してAIに任せられるかどうかは、この3つにかかっています。
見える ── 全処理のログ化とリアルタイム可視化
AIが何をしたのかが後から追え、いま何が動いているのかが常に見える状態を、標準装備にしています。承認も、修正も、差し戻しも、モードの変更も、すべて記録に残る。これは監査のためであると同時に、「ブラックボックスに任せている」という不安をなくすためでもあります。見えないものは、人は信用できません。だから見えることを、機能ではなく前提として置いています。
止められる ── 緊急停止スイッチ
何かがおかしいと感じたとき、一手で全自動処理を止め、手動運用に切り替えられるようにしています。これは平常運用のモード切替とは別物として、はっきり目立つ形で用意しました。車のブレーキと同じで、めったに強く踏まないとしても、「いつでも踏める」という事実そのものが安心を生みます。押せば止まる、という保証が、任せる勇気の裏づけになります。
戻れる ── 手動運用への戻り道と三つのモード
停止は破棄ではありません。止めても案件はデータとして残り、人がそのまま手作業で続けられます。AIが止まっても業務は止まらない——この戻り道を常に確保しておくことを、私たちは強く意識しました。
さらに工程ごとに、完全自動・人間承認・手動の三段階モードを持たせています。最初から全部を自動にするのではなく、精度が確かになった工程から自動化の度合いを少しずつ上げていく。信頼は一度に渡すものではなく、実績を見ながら段階的に預けていくもの——この段階的自動化も、安全設計の一部です。
永続を約束せず、自立可能性を約束する
私たちは「このシステムが20年動き続けます」とは約束しません。技術の変革スピードが限りなく加速していく時代に、そんな約束をするのはむしろ不誠実です。
当社では、データは顧客名義のインフラに、標準的な開ける形（PostgreSQL）で残します。業務のロジックも、引き継げる形で残します。置き換え不可能な資産はデータだけだからです。仮に私たちが関われなくなっても、会社に残るのは、これまでに構造化された受注・見積のデータと、言葉として書き起こされた判断の蓄積です。
これは事業承継の場面で、そのまま企業価値になります。ベテランが去っても、その判断の記述とデータが残っていれば、後継者はゼロから勘を作り直さずに済む。会社が売却される未来でも、整った形で残るデータは買い手にとっての価値になります。永続するのはシステムではなく、顧客の自立可能性——これが、私たちと顧客の約束です。
まとめ
AIエージェントが業務を代行していく流れは、必然だと考えています。
だからこそ、その必然を中小の現場に安心できる形に落とすことに、私たちはそれに時間をかけました。ヘッドレス基幹・承認駆動・統制つきの自律という三つのコアは、その必然から逆算した帰結であり、それを支えるデータ主権や権限レス、そして止められる・見える・戻れるという安全設計は、現場に置くための最低条件でした。
賢いAIを作ることより、安全に任せられる境界を設計すること。止められて、見えて、戻れること。必然の流れを、現場が安心して迎えられる形にすること。我々はそれを最初に決めるという、AIエージェント導入を掲げる他の会社とはまったく違うアプローチを選びました。
コメント