By Jay Revels, Ichizoku株式会社 CEO
本記事は、AIツールを買い足すだけでは変革が起きない理由をコードだけが持つ2つの優位性から解き明かし、FDE（Forward Deployed Engineer）が業務を監査してAIを組み込む手法までを解説します。
重要なポイント
- ライセンス購入という幻想：Copilotを大量にそろえても、変わらない業務プロセスにAIを後付けするだけでは変革は起きない
- ソフトウェアだけが先行できた理由：コードには統一されたコンテキストと即時検証という優位があり、他の業務にはどちらも存在しない
- コード以外の業務が行き詰まる3つの箇所：コンテキストが十数個のSaaSツールに分散し、人はAIの提案を避け、成果物を検証する手段がない
- FDEによる3レイヤー設計：暗黙のワークフローまで監査し、処理を決定論的コード・AIエージェント・HITL（Human-in-the-Loop）へ振り分ける
Copilotのライセンスを500席分購入しても、AIトランスフォーメーションにはなりません。高価なだけで、使われないまま眠るソフトウェアになってしまいます。
本当の変革に必要なのは、業務が社内を流れる経路そのものを作り直すことです。2018年から変わらないプロセスにAIを後付けするだけでは、変革は起きません。
多くの経営者は、AI予算の90％をGPT-4やClaudeなどのモデルに注ぎ込みます。しかし業務の流れ自体は変えないままです。そして18カ月後、もちろん承認フローも引き継ぎもサイクルタイムも以前とまったく変わっていません。原因は明らかであるにもかかわらず、なぜ成果が出ないのかと、さも意外そうに首をかしげます。
基盤モデルの知能自体はすでにコモディティ化し、競合もまったく同じモデルを、まったく同じ価格で利用できます。真の価値はモデルそのものではなく、モデルを業務に組み込むために構築した運用と実装の仕組み側にあります。
ソフトウェアエンジニアリングがこのことに早くから気づけたのは、コードに2つの反則的な優位性があるためです。
1. 統一されたコンテキスト：コードは1つのリポジトリに集約され、完全な変更履歴がバージョン管理されている
2. 即時検証：テストスイートを実行すれば、ビルドが成功するか失敗するかが分かる。エンジニアはdiffを見れば、30秒で正しく動作するかどうかを判断できる。
それ以外のあらゆる業務機能は、例外なく次の3つの箇所で行き詰まります。
1. コンテキストが十数個のSaaSツールに分散している
チームが本当に持っているコンテキストは、Slackのスレッド、CRMのメモ、あちこちにあるGoogleスプレッドシート、録音された通話などに散らばっています。そのためワークフローを再設計することも、業務全体をエンドツーエンドで可視化することもできません。結局、壊れた工程の一つにAIを後付けし、それを「進歩」と呼んで済ませてしまいます。
2. 人間はAIの提案を避け、従来のやり方を続ける
変わっていない承認フローにAIを組み込んでも、AIの提案は「任意の提案」にとどまります。相変わらず5人分の承認が必要で、引き継ぎのフローも変わりません。旧来のインセンティブ設計が、従来どおりのやり方を続けさせてしまいます。
3. コード以外の成果物は検証できない
提案書、需要予測、法務要約、GTM戦略にはユニットテストがありません。確率的なAIの出力が人間による成果物を上回ることを自動的に証明する方法がないため、誰もAIを業務の中核には組み込みません。結局、一部の熱心な従業員が金曜日に開く程度のサブツールにとどまってしまいます。
こうしたやり方が、エンタープライズAIの標準です。従来型のソフトウェアエンジニアにAPIキーを渡し、技術に明るくない事業リーダーに確率的な仕様書を書かせ、あとはうまくいくのを祈る。これでは、うまくいくはずがありません。
従来の決定論的なソフトウェア開発の手法では、非決定論的で確率的なAIシステムと、雑然として明文化されていない業務の現実には対応しきれないのです。
Ichizokuの解決方法：FDE（Forward Deployed Engineer）
Ichizokuは FDE（Forward Deployed Engineer）によってこのギャップを埋めます。
FDEは普段ほとんど接点のない2つの領域を橋渡しします。1つはワークフロー、インセンティブ、ボトルネックといった業務の現実。もう1つは確率的なモデル、API連携、決定論的なコードといった技術アーキテクチャです。
FDEは「請求書PDFから合計金額を抽出する」といった表面的なタスク目標だけを見て、システムを設計することはしません。現場に入り込み、ワークフローそのものを監査します。明文化されていないエッジケース、レガシーな例外処理、手作業による回避策など、日々の業務の80％を占める部分に踏み込みます。
そのうえで、FDEはAIの実行方法を役割の異なる3つのレイヤーに分けて設計します。
- 定論的なコード：厳格なビジネスルールやセキュリティを担保するためのハードコードされたロジック
- エージェンティックな推論：複雑なロジックやエッジケースを処理するAIエージェント
- HITL（Human-in-the-Loop）：「ドラフト＆レビュー」→「例外ルーティング」→「事後監査による監督」のように、人間の関与を段階的に移行する設計。
Ichizokuは既存のERPやCRMを置き換えず、その上にオーバーレイ型のアーキテクチャを構築します。さらに、本番環境で厳密なベンチマーク評価（Evals）を継続的に実施し、時間の経過とともにシステム性能がドリフトすることを防ぎます。
エンタープライズのお客様との協業
Ichizokuはソフトウェアのサブスクリプションを販売して終わりにすることも、ROIの低い戦略コンサルティングを延々と続けることもしません。真の業務変革を次の2つの軸で実現します。
- 直接的なデプロイと統合
FDEがお客様の業務チームに伴走し、実際のワークフローを監査します。文書化されていないプロセスを可視化し、オーバーレイ型のアーキテクチャを設計したうえで、本番運用に耐えるエージェンティックなシステムを重要な業務プロセスに直接組み込みます。 - FDE人材の育成
AIの成熟度を高めるうえで最もROIの高い方法は、この能力を社内に築くことです。FDEトレーニングプログラムを通じて、ビジネスアナリスト、システムエンジニア、業務リーダーなど、自社の業務をすでに深く理解している人材を実践的なFDEへと育成します。
AIツールを単なる追加オプションとして購入するのはもう終わりにしましょう。
非決定論的なナレッジワークをテスト可能で拡張性のあるビジネスロジックへ変えることをお考えでしたら、ぜひIchizokuにご相談ください。
【FAQ】よくある質問
1. Copilotのライセンスを大量に購入すれば、AIトランスフォーメーションは実現できますか？
実現できません。業務が社内を流れる経路そのものを作り直さない限り、AIは高価なまま使われないソフトウェアになります。
2. AI予算の多くをモデルに投じても成果が出ないのはなぜですか？
業務の流れ自体を変えないためです。承認フローも引き継ぎもサイクルタイムも以前のまま残り、18カ月経っても変化は生まれません。
3. なぜソフトウェアエンジニアリングは早くからAIを業務に組み込めたのですか？
コードに統一されたコンテキストと即時検証という2つの優位性があるためです。1つのリポジトリに履歴が集約され、テストを実行すれば動作をすぐに確かめられます。
4. コード以外の業務がAI活用で行き詰まるのはどこですか？
3つの箇所です。コンテキストが十数個のSaaSツールに分散し、人はAIの提案を避け、成果物を検証する手段がありません。
5. FDEはこれらの課題をどのように解決しますか？
現場に入り、日々の業務の80%を占める暗黙のワークフローまで監査します。そのうえで処理を決定論的コード・AIエージェント・HITLの3レイヤーへ振り分け、既存のERPやCRMの上にオーバーレイ型で組み込みます。