1つ目は、「現場の担当者に思考や判断のプロセスが見えない」ことだ。AIは結果を出力するものの、AIが何を考えどのように判断したのか、そこに表出された指示が正しいのかどうかが、分からないという現場担当者の声が大きかった。

　在宅ワーカーや後輩に本当に正しい指示として伝えられるものかどうか自信が持てず、結局出力結果を1件ずつ全てチェックして業務を進めなくてはならなくなり、かえって社内工数を跳ね上げてしまった。

　2つ目は、「使っても楽になった感じがしない」という声だった。文字起こしからリスト、トーク、ディレクションへのワークフロー自体は成立していた。しかし、3つを一気通貫で進めているのは結局、人だった。「次に何をするか」「いつ終わるか」を人が考えて指示しており、AIは「タスク実行係」のままだった。コストは下がったものの、もともとクラウドワーカーが担ってきた作業がAIに変わっただけで、社内の運用負荷は減らなかった。

「対話」と「AI司令塔」が解決策

　竹ノ内氏は、失敗の原因が「AIが少し入って自動判定するだけのただのシステム」であったことだと語った。「入力すると結果が出てきて、途中経過は人に見えない沈黙の箱」ではなく、お互いに対話しながら仕事を一緒に進める「同僚」を作らなくてはならない。それが失敗から学んだ教訓だった。

　この考えのもと、竹ノ内氏は「司令塔のAIエージェント」配下に各業務の「サブAIエージェント」を配置する構成に再編した。

　「リスト」「トーク」「ディレクション」の3領域をそれぞれのサブAIエージェントが担い、それらを束ねる司令塔AIエージェントがそれぞれに指示を出す。人間は司令塔AIエージェントとだけ対話し、営業支援プロセスの1つの完了（ゴール）を受けて次のプロセスを担うサブAIエージェントに指示を出す。

　進捗は司令塔AIエージェントが把握し、アルゴリズムでワークフローを判定して、状況の聞き取りなどはAPI経由でAIが担う。このようにAIが担う部分とアルゴリズムで解決する部分を明確に分けたことも新しい構成の特徴だ。

　人間はプロセスを非常に大事にし、そこから納得して合意する。ただし、推進まで人が担っては意味がない。決められた情報をもとに、アルゴリズムやエージェントが推進する仕組みが整った。

　ここまでやって初めて社内に普及し始める構造が見えてきたと竹ノ内氏は言う。それが2026年4月の初めだった。以降、同社はこのフォーメーションを軸に、全業務のAI化を進めている。

　竹ノ内氏は2026年5月ごろからこのやり方を拡大し、金額的なメリットを試算して数値化している。

人件費とAPI利用料の差（同一作業）は約55～60倍

同じ作業を人とAIそれぞれで行い比較した同社の実測値。差は業務によって異なる

AI代替による業務委託費の削減効果は月間約3000万円

在宅ワーカー委託業務のうち、AIの方が品質・コスト面で優れるものを順次切り替えた結果の業務委託費削減額（同社実績）

　開発スピードは速くなり、コスト面でもAI開発が優位になるとの算定だ。もちろん同社固有の業務背景もあり、必ずこのような効果が得られるとは限らないものの、これからAI開発に取り組む企業には、大いに期待が高まる数値ではないだろうか。

自社でAI開発を実装するための実践的ポイント

　さらに竹ノ内氏は、自社での取り組みの経緯と成果をもとに、AI開発の実装のための重要ポイントを解説した。ステップは「業務選定」→「計画」→「開発」→「テスト」→「オンボーディング」の5つだ。前提となる考え方は「同じ業務でも、業務アプリや自動化、AIエージェントといった仕組みを足すほど、人が手を動かす場面は減る」ということだ。

　仕組みを加えて自動化領域を拡大させると、人間は判断や顧客対応など、本来やるべき仕事に集中できる。しかし、このような段階を一足飛びに実装することは難しい。同氏は前述したステップで着実に進めることをアドバイスした。

「業務選定」選ぶ業務で9割が決まる。3軸＋2軸による選定

　成功の最も大きな要素が、どの業務から手をつけるかといえる。選ぶ軸は次の3つだ。

　1つ目は「属人化している業務」だ。トッププレイヤーのベストプラクティスや暗黙知をAIに移植すれば、組織全体のパフォーマンスを底上げできるだろう。

　2つ目は「反復している業務」だ。毎日、毎週同じ手順を繰り返している業務は、削減効果が読みやすく、投資回収がしやすい。

　3つ目は「判断軸が言語化できる業務」だ。「こうなったら、こうする」というノウハウを言語化できないとAIも学習できない。これが業務選定の境界線になる。

　候補業務を3軸で洗い出したら、次に「効果」と「実装容易性」の2軸で並べ替える。

　「効果」は、削減できる時間を想定し、リスク管理の観点から負荷やミスを含めて総合的に判定する。「実装容易性」は、「Claude Code」や「Codex」などに渡すべき裏側のデータがそろっているかどうかだ。そろっていなければデータ作成から始めることになり、難易度が上がる。

　効果と実装容易性によって候補業務を並べ替え、1位になった業務から着手する。効果はほどほどであっても実装が簡単な業務を優先し、小さな成功体験を作っていくことが社内の空気を変えるきっかけになると竹ノ内氏は言う。

「計画」対話シナリオを先に書く

　業務を選んだら、次は要件定義のフェーズだ。竹ノ内氏は現在、要件定義そのものもAIと対話しながら作っているという。つまり対話のシナリオを先に書くということだ。ユーザーとAIがどういう会話をし、何が出てくるかを設計したうえで、「こういうことができるAIエージェントを作りたい」と伝えて要件定義を任せる。司令塔と人の会話の流れをサンプルで20往復ぐらいした結果が、そのまま仕様書になる。書けない部分は設計があいまいな部分ということになる。

　一例としては、「ChatGPT」で要件定義して確認した後にClaude Codeへ渡し、Opus 5.5で開発を始める流れだ。

「開発」最小単位で作り、チューニングで育てる

　開発は、スコープ全体を最初から対象にすると失敗しやすい。まずは1つ2つの機能を軸に開発し、デプロイして動かしてみる。問題がなければ次の機能を継ぎ足す。「司令塔→サブ1つ→結果→司令塔」の往復（最小ループ）が回ってから機能を足す。こうすることにより、問題が発生したときにその箇所を特定しやすくなる。

　作った後は、チューニングで品質を育てる。このときの品質基準はAI任せでなく、「○％以上の精度」「○分以内に返す」「○件中○件は人手なしで完結」のように明確な数値で合格ラインを引く。竹ノ内氏自身は、「辛口で100点満点になる状態で成果物を出してくれ」と伝えているという。そうすると、かなり高品質なものが出てきやすい傾向にあるとのことだ。

「テスト」と「オンボーディング」　動いたで終わらせない

　AI開発の後にはテストとオンボーディングが必要になる。この部分こそが一番難しい領域だと竹ノ内氏は語った。開発がスピードアップしても、レビューする人が足りず、最終的な完成までのスピードは速くならない事象もある。これに対して竹ノ内氏は「テストは、動くかどうかではなく使えたかどうか」であり、現場で使ってもらい、機能が動くかよりも業務フローに収まるかを評価する。不具合よりも「ここで迷う」「ここで止まる」というフィードバックを集めることにフォーカスしているという。

　利用率を上げていくオンボーディングのプロセスも重要だ。同社では、次のようなやり方をとっている。

　「マニュアルは配るがだいたい読まれない」と竹ノ内氏は語った。多忙な社員に新しいシステムを使ってもらう際は、特に適した業務を1つ決めて、1時間かかる資料がボタン1クリックで出てくるような驚きや感動を与える機能を披露する。さらに、社内への情報伝搬力をもつ人を中心に横にその情報が広がるようにすると「あの人がそう言うなら」と使いたくなる社員が増えるという。「トップダウンの号令より、横への伝搬のほうが10倍速い」というのが同氏の実感だ。

　こうした新しい開発の流れに再編した同社では、現在約15体のAIが動いていて、毎月2体ずつ増やしている状況だ。それらAIを束ねるための独自AIプラットフォーム「デジタルワークス」（DigitalWorks）を構築し、依頼に応じてワークフローを自動完結させる仕組みを整えたという。これらのAIは自社利用だけでなく、外部提供もしている。

　最後に、即座に実践できる手順は次の通りだ。初日～1週間で次のことを実行してみることを竹ノ内氏は勧めた。

1．上記の3軸＋2軸での業務選定により1業務を選ぶ（所要時間30分）

2．選んだ業務について「司令塔と人」の対話シナリオを書いてみる。業務シナリオを作成できたら実装に進む。書ききれない部分があれば、設計があいまいである証拠であり、再考が必要。（初週）

　1週間で最小ループが回り、社員の驚きや感動を得られれば、開発を次の段階に進めやすくなる。「動かして終わり、ではない。AIに、AIを磨かせ続けてほしい」と竹ノ内氏は締め括った。