AI内製化はモデルを作ることではない——Copilot「仕事OS」と9割停滞が示す状態・権限・完了条件

AIを自社で使いこなすために、独自モデルや専用アプリを作るべきでしょうか。2026年9月、Microsoftはチャット、アプリ作成、常時動くエージェントを一つにまとめた新しいCopilotを「仕事のための新しいOS」と位置付けました。同じ時期、日本発のEdgeCortixは最大3.36PFLOPSをうたうフィジカルAI向けチップレットを発表しました。使えるソフトウェアと計算資源は、急速に増えています。

ところが、日本企業のAI内製化を扱った国内調査では、社内主導プロジェクトの停滞や頓挫を経験した回答者が9割近くに達しました。不足していたものとして技術基盤を挙げた割合は18.6％にとどまり、最も多かったのは経営課題や業務課題をAI活用へつなげる力でした。道具が増える速度と、仕事を変える速度は一致していません。

このずれを埋めるには、内製化の意味を変える必要があります。モデルや画面を自作することではなく、何のために動かすか、今どこまで進んだか、誰の権限で何をしてよいか、何をもって完了とするかを自社で保持することです。本稿では、この四つを「目的・状態・権限・完了条件」として整理します。

AI内製化の目的と業務状態を確認する日本企業のチーム会議

9割近い停滞経験が示すのは、AI技術より仕事の定義不足

＠ITが紹介したTWOSTONE&Sonsの調査は、従業員300人以上の企業で全社的なAI・DX推進に関わる経営層と責任者111人を対象にしています。調査は事業者による小規模な自己申告調査であり、日本企業全体の失敗率とみなすことはできません。それでも、どこで足が止まるのかを考える材料になります。

社内主導のAIプロジェクトが期待した成果や規模へ届かず、停滞または頓挫した経験について、「数回ある」は55.9％、「何度もある」は31.5％でした。行き詰まりやすい段階で最も多かったのは、AI活用の目的やテーマを決める段階の57.7％です。始める前には十分認識していなかったが実際には重要だったこととして、戦略・構想の設計が58.6％、実装・開発人材の確保が45.9％、構想を実装計画へ落とすことが43.2％と続きました。

停滞を経験した102人が自社に不足していたと答えた項目では、経営課題・業務課題をAI活用へつなげる力が58.8％で最多でした。実装人材は50.0％、設計力とPM／PMO人材はそれぞれ49.0％です。一方、AIツールやシステムなどの技術基盤は18.6％でした。

この数字から「技術は不要」と結論付けるのは早計です。調査が示すのは、技術だけを先に用意しても、対象業務、責任者、移行手順、合格条件が曖昧なら本番へ進めないという順序です。最新モデルの契約や社内チャット画面の公開は目に見えるため、導入実績として報告しやすいでしょう。しかし、請求処理一件をどこからどこまで終わらせるか、例外時に誰へ戻すか、誤処理をどう訂正するかは、業務部門と一緒に決めなければなりません。

停滞の影響も軽くありません。調査では、投資の縮小・凍結が56.9％、本格導入や全社展開の遅れが55.9％、現場の不信感や抵抗感の高まりが53.9％でした。失敗した試作を一つ片付けるだけでなく、「AIはまた途中で止まる」という組織記憶が残ります。次の案件では、精度の説明より先に、前回と何が違うのかを示す必要が生じます。

Copilotの仕事OS化で、内製対象はアプリから運用状態へ移る

AIエージェントの状態と利用量を管理する業務ダッシュボード

The Vergeによると、新しいMicrosoft CopilotはHome、Code、Autopilotの三つの領域を一つの画面へまとめます。Homeはチャットと共同作業を集約し、メール、会議依頼、Teamsのやり取りなどから仕事の現在地を示します。Codeは自然言語から社内アプリ、追跡画面、自動処理を作り、組織のテナント内に置けると説明されています。

Autopilotは、人が席を離れている間もクラウド上で動き、Teamsの監視、定期作業、後続対応などを担う構想です。Microsoftは、Autopilotが固有の身元、記憶、コンピューター、作業空間を持ち、権限、監査、統制の下でTeamsやOutlook、文書へ現れるとしています。チャットに質問して回答を受け取る段階から、会社の中で継続的に仕事を持つ主体へ近づいています。

重要なのは、便利な機能が一画面に増えたことだけではありません。従来の内製では、社内アプリのソースコードとデータベースを自社が持てば、かなりの部分を管理できました。エージェント型の仕事では、同じ画面でも次の状態が刻々と変わります。

どの依頼を受け取り、どこまで処理したか
どのメール、会議、文書を根拠にしたか
誰の代理として、どの権限を使ったか
いくらのモデル利用量と実行時間を消費したか
どの例外で止まり、誰の判断を待っているか

新Copilotでは、Cowork、Code、Autopilotの一部が利用量に応じた課金となり、長時間動くエージェントや高性能モデルの利用も費用管理の対象になります。これはAIの停止時間・トークン・越境範囲に依存予算を置く考え方と直結します。作ったアプリの本数ではなく、完了一件当たりの実行回数、時間、費用、人の介入を測らなければ、内製の経済性は分かりません。

プラットフォームが固有の身元や記憶を提供しても、会社の業務目的まで自動で定義してくれるわけではありません。毎朝のダッシュボードに表示する情報、夜間に進めてよい処理、承認なしで送ってよい連絡、止めるべき費用上限は、自社側の設計です。内製すべきものは、基盤の複製ではなく、基盤へ渡す業務契約だと言えます。

AIは会話を覚えているように見えて、静かに文脈を落とす

O’Reilly RadarでAndrew Stellman氏は、AIとの長い作業中に会話が圧縮され、少し前に取ったメモへアクセスできなくなった経験を紹介しました。画面を上へ戻れば人には見えるのに、AIの作業文脈からは消えていたという例です。

長い会話では、古いメッセージを切り捨てる、要約へ圧縮する、挙動が不安定になるなど、製品ごとに異なる形で文脈が失われます。厄介なのは、AIが「何を忘れたか」を必ずしも申告しないことです。残っている情報だけで、もっともらしい出力を続ける場合があります。

この問題は、モデルのコンテキスト長を伸ばすだけでは消えません。仕事の期間や資料量も同時に大きくなり、複数のチャット、担当者、モデル、アプリへまたがるからです。今日の会話を明日のエージェントへ渡すとき、会話履歴そのものを唯一の記録にすると、どの決定が有効で、どれが古く、何が未完了かを判別しにくくなります。

Stellman氏は、発見と文書化を別工程にする、古い会話を続ける代わりに引き継ぎ文書を作る、手順の長い列ではなく受け入れ条件を置く、複数AIの橋として仕様書を使うという四つの方法を示しています。ここで価値があるのは特定のファイル名ではなく、重要な状態を会話の外へ出し、人も別のAIも読める形にすることです。

AIとの会話から業務仕様と引き継ぎ記録を外部化する作業

例えば「四回確認して報告する」という手順は、途中の回数をAIが見失う可能性があります。「四回分の結果が検査表へそろうまで完了ではない」という条件なら、現在の成果物から判定できます。過去の記憶に依存する手順より、現在の状態を調べられる合格条件の方が、文脈圧縮に強いのです。

これは、以前整理した検索・判定・生成・実行を一つの万能AIへ詰め込まない設計を、時間方向へ延ばした考え方です。工程を横に分けるだけでなく、日をまたぐたびに状態を受け渡します。どの工程が終わり、どの根拠が使われ、どの判断が保留されたかを外に残せば、モデルを替えても仕事を再開できます。

3.36PFLOPSが増えても、目的と完了条件は生成されない

EdgeCortixが発表したRAIDENは、1個、2個、4個のコンピュートダイを組み合わせるモジュール型のチップレット構成です。最大構成のRAIDEN X4はFP4で最大3.36PFLOPSとされ、同じ精度表現で比較したNVIDIA Jetson AGX Thorの約1.6倍だと同社は説明しています。2027年初頭のサンプル提供、同年後半の量産が計画され、川崎重工業では次世代の航空宇宙・防衛製品を想定した開発が始まっていると報じられました。

この数値は事業者の公称最大性能であり、実際の業務速度、精度、消費電力、ソフトウェア移植性を直接保証するものではありません。FP4の演算量を、異なる精度や処理内容のシステムと単純比較することもできません。ただし、現場に近い場所で大規模なAI処理を行う選択肢が広がっていることは分かります。

RAIDENは最大256GBのLPDDR5X、ダイ間の高速接続、RISC-Vコアを備え、既存製品向けのソフトウェア成果をMERA 3.0へ引き継ぐ構想です。つまり、半導体の性能だけでなく、過去のモデルや開発資産を新しい世代へ持ち越せることが採用条件になります。ハードウェアにも引き継ぎ設計が必要です。

エッジAIの計算資源と業務システムの接続境界を確認する技術者

工場、物流、店舗、交通などでエッジAIを使うと、通信遅延を減らし、機密データを現場内へ置き、クラウド障害時にも一部処理を続けられる可能性があります。一方で、現場装置が何を検出し、どの数値で停止し、通信復旧後にどの記録を同期するかは、チップの演算性能からは出てきません。

計算資源を自社施設へ置くことと、仕事を自社で制御できることは別です。目的、権限、状態、完了条件がクラウドの設定画面や担当者の頭の中にしかなければ、国産チップを使っても運用は属人的になります。逆に、この四つを持ち運べる文書とデータ構造にすれば、クラウド、社内サーバー、エッジ装置を業務ごとに選び直せます。

内製化で自社が持つべき四つの資産

AI内製化を「全部を自社開発する」から「仕事を選び直せる状態を持つ」へ変えると、保持すべきものが明確になります。

自社資産	最低限記録する内容	外部サービスへ任せられる部分	失うと起きること
目的	対象業務、利用者、減らす負担、守る品質、対象外	モデル候補や実装案の提案	高性能でも不要な仕事を自動化します
状態	案件番号、現在工程、根拠版、決定、保留、次の担当	会話要約や候補抽出	会話終了やモデル変更で途中経過が消えます
権限	依頼者、代理主体、読取・作成・送信・決済の上限	認証基盤や監査ログの保管	便利なエージェントが境界を越えます
完了条件	必須成果物、合格値、例外処理、人の承認、訂正方法	自動試験の実行	出力しただけで終わったことになります

目的は「AIを導入する」では足りません。例えば、問い合わせ業務なら、回答時間を縮めるのか、担当者が探す資料を減らすのか、誤案内の訂正を速くするのかを分けます。複数の目的を一つの指標へ混ぜると、回答速度だけ改善して訂正件数が増えても成功に見えてしまいます。

状態は、会話の全文保存だけではありません。採用した根拠、却下した案、現在有効な決定、未解決の争点、次の担当を短く構造化します。個人情報や機密情報を無期限に残すのではなく、再開に必要な最小量、保存期間、削除責任者も決めます。

権限は、参照と実行を分けます。予定表を読めること、会議案を作れること、招待を送れること、外部参加者を追加できることは別の権限です。プラットフォームが一つの同意画面にまとめていても、社内の仕事では段階を分けます。

完了条件は、人が逐一画面を見張らなくても結果を検査できる形にします。請求書なら金額と取引先の一致、承認記録、会計システムへの登録、振込前の停止までを一件として定義できます。文章作成なら、出典、禁止表現、対象読者、承認者、公開先がそろった時点を完了にします。

五つの小さな文書で、会話依存を減らす

大規模なAI基盤を買う前に、一つの業務へ五つの記録を置けます。形式は表計算、社内Wiki、チケット管理、JSONなどで構いません。重要なのは、AI製品の会話履歴から独立して読めることです。

目的票

一件の業務について、誰のどの負担を減らし、何を悪化させてはいけないかを書きます。「議事録作成を自動化」ではなく、「会議後30分以内に決定事項と担当者を参加者へ返し、未確認の発言を決定扱いしない」とします。

状態票

現在工程、参照した資料の版、確定事項、仮定、保留、次の一手を記録します。AIが要約を作っても、人または検査処理が原資料との差分を確認します。長い会話を再読しなくても、新しい担当者が再開できる量へ絞ります。

権限票

誰の代理で、何を読み、何を作り、どこへ送れるかを列に分けます。金額、宛先、公開範囲、実行時間帯など、数値化できる上限も置きます。権限変更には日付と承認者を残します。

合格票

「良い回答」のような主観だけでなく、必須項目、許容誤差、停止条件、再試行上限、承認者を記録します。AIに手順を覚えさせるより、現在の成果物が条件を満たすかを毎回判定します。

引き継ぎ票

終了時に、完了済み、未完了、変更された条件、残るリスク、次の担当を出力します。新しいAIセッションだけでなく、休暇明けの人間、別部署、外部支援会社への移管にも使えます。外部AI人材から目的・判断・知識・運用・継続を移す設計と組み合わせれば、支援終了後の依存も減らせます。

30日で「AIを作る」から「一件を引き継げる」へ変える

最初から全社基盤を完成させる必要はありません。AIがすでに使われている一業務を選び、30日で引き継ぎ可能性を試します。

1週目は目的と一件の境界を決める

対象業務を一つに絞り、開始入力と終了成果物を決めます。現状の人による時間、待ち時間、差し戻し、訂正、例外件数を測ります。AIの性能ではなく、仕事一件の基準線を作ります。

2週目は状態と権限を外へ出す

会話に埋もれている決定を状態票へ移し、参照、作成、送信、実行を分けます。最初は読み取りと下書きだけを許し、外部送信や更新は人の承認後にします。使わない権限は与えません。

3週目は新しい担当へ渡す

同じ担当者が続けるのではなく、新しいAIセッション、別モデル、別の社員のいずれかへ切り替えます。過去チャットを見せず、五つの記録だけで一件を再開できるかを試します。不足した情報は、会話へ戻すのではなく記録の項目へ追加します。

4週目は完了と縮退を試す

通常系だけでなく、資料不足、権限不足、予算上限、外部サービス停止を入れます。AIが止まった後、人が同じ案件番号から再開し、期限内に一件を閉じられるかを測ります。成功率だけでなく、引き継ぎ時間と訂正時間を残します。

30日の終了時には、次の七つを確認します。

目的を一文で説明できる業務の割合
過去チャットなしで再開できた案件の割合
引き継ぎにかかった時間
権限不足で安全に止まった件数
権限過多で不要な操作が可能だった件数
完了一件当たりのモデル費、人の確認時間、再作業時間
AI停止後も期限内に完了できた案件の割合

これらは「AI利用者数」や「生成回数」より地味です。しかし、全社展開に必要なのは、利用が増えても目的と責任が薄まらず、担当や製品が変わっても仕事を続けられることです。

主な出典

結論——内製化の成否は、次の担当が再開できるかで測る

AIのソフトウェアは、チャットからアプリ作成、常時稼働するエージェントへ広がっています。計算資源もクラウドだけでなく、社内や現場へ置ける選択肢が増えています。それでも、目的、状態、権限、完了条件が会話と担当者の頭の中に残ったままなら、道具が新しくなるたびに仕事を説明し直すことになります。

内製化は、すべてを自社で作る宣言ではありません。外部モデルやプラットフォームを使いながらも、対象業務を選び、途中状態を取り出し、権限を狭め、完了を自分たちで判定できる状態です。その状態があれば、製品を替え、担当を替え、クラウドとエッジを選び直せます。

来週、いま動いているAIの会話を閉じ、別の担当者へ五つの記録だけを渡してみてはいかがでしょうか。そこで一件を再開できれば、内製化は画面の中ではなく、組織の仕事として始まっています。再開できなければ、次に買うべきものは新しいモデルではなく、失われた目的と状態を書き戻す時間です。