失敗パターン:要件収集型AX
AXチームを作り、各部署を回って要件を収集し、要件通りにツールを作って納品する。合理的に見えるこの構造が繰り返し失敗する理由は単純です。現場がそのツールを使わないからです。AIが業務を一つ消せば、その時間をより生産的な仕事に移すのが会社の期待ですが、実際のインセンティブは逆に働きます。今の地位まで苦労して身につけた仕事のやり方が自分の存在証明である人にとって、その仕事をやめろという圧力は歓迎されません。
成功するAXの出発点:業務をなくし、人を移せ
4年間自らAI事業を運営してきたノ・ジョンソク代表の結論は明確です。成功するAXは「あのチームを助けてください」ではなく「あのチームの業務単位を丸ごとなくしてください」から出発します。これは解雇の言葉ではありません。業務単位を完全に取り除き、その人を新しい職務へ転換させる設計です。既存業務にツールを上乗せする方式は、結局ExcelとPowerPointを別のツールに替えるだけに終わり、会社レベルの生産性向上は起こりません。
ツールは作らないのがベスト — 純正バニラ構成
もう一つの直感に反する結論は、効率化ツールを自作するなということです。社内であらゆるフレームワークと自作エージェントを試した末に残った答えは、データコネクタをきれいに作り、ドメインを理解したプロンプトを丁寧に書き、フロンティアモデルにClaude Codeのような実績あるハーネスをつなぐ構成でした。自社開発のどの組み合わせよりも、この素朴な構成の性能が良かったのです。
良いプロンプトを書く力は、エンジニアリング能力ではなくドメイン理解から生まれます。その業務が実際どう回っているか、データがどんな形かを知る人が書いたプロンプトが仕事を終わらせます。
AXコンサルティングが点検すべきこと
SH ConsultingがAXコンサルティングでツール製作より先に見るのは2つです。どの業務単位を丸ごとなくせるか、そしてその仕事をしていた人をどこへ転換させるか。この設計なしにツールだけを供給するAXは、予算を使っても組織を変えられません。