「AIが書いたコードは、AIにレビューさせたほうが速くて正確だ」開発の現場では、そんな声を聞くことが増えてきました。 実際、AIを開発に取り入れて成果を大きく伸ばした企業も出てきています。2026年7月、カーネギーメロン大学とスタンフォード大学の研究チームが、ある中堅ソフトウェア企業の約2年分の開発データを分析した論文を公開しました（査読前のプレプリントとしてarXivで公開）。この会社では、開発者1人あたりの成果がおよそ2倍になっています。 ただ、論文が本当に伝えようとしているのは、その「2倍」の裏側で起きていたことです。 では、AIで開発のスピードが上がったとき、会社の中では何が変わったのでしょうか？ 私は、そこに企業がAIに仕事を任せていくためのヒントがあると考えています。
「AIは、それらしい答えは返してくれる。でも、仕事の判断まで任せるのはちょっと怖い」AIエージェントの活用を考えている企業では、そんな声をよく聞きます。 一方、個人向けAIの世界では、状況が大きく変わり始めています。 2026年9月、Metaは米国とカナダで個人向けAIエージェント「Muse」の提供を開始しました。メールの送信、旅行の予約、買い物、料金交渉など、これまで人が行っていた作業をAIが代わりに進めてくれます。 では、なぜ個人の生活ではAIが動き始めているのに、会社の中では「判断を任せる」ところまで進まないのでしょうか？ 私たちは、その理由の一つが「AIが参照できる知識」にあると考えています。
昨日のGoogleトレンドの急上昇ワードに「楽天モバイル ローミング終了」が入っていました。
この連載では、基幹システムの中に残っている業務知識を、一つひとつ読み解き、AIが使える形に整え、育てていく方法を書いてきました。 Vol.01 では、「業務知識がどこにあるのか」。 Vol.02 では、「どう読み解き、どう更新し続けるのか」。最終回では、その知識を整理すると何が変わるのか、そして最後に「その資産は誰のものか」を考えます。 基幹システムの刷新、社内AIの活用、ベンダー選定。それらに関わる方の判断材料になればと思います。
既存システムに残っている業務知識を知ろうとしても、コードを読むだけでは十分ではありません。コードから分かるのは、システムが実際にどんな処理をしているかです。なぜその処理が必要なのか、現場でどのように使われているのかまでは、コードだけでは分からないことがあります。 そこで、運用ログや設計書、手順書も合わせて見ます。書かれていることと実際の動きが合っているかを確かめ、食い違いがあれば、その理由を調べます。 もう一つ大切なのは、一度整理した知識も、業務が変われば古くなるということです。最初にどれだけ丁寧につくるかだけでなく、その後も更新できる仕組みが必要になります。 前回は、AIの進歩によって、これまで人手では割に合わなかった作業が現実的になりつつあること、そして知識は一度つくって終わりではないことを書きました。今回は、この二つの中身を順に見ていきます。
企業の競争力を支える業務知識は、文書・人・コードの中に分散し、見えないまま失われつつあります。そして、知識は「存在する」だけでは使えず、AI時代には人とAIの双方が読める形で構造化されていることが重要です。 そのために、埋もれた業務知識を取り戻し、オントロジーとして「育て続けられる資産」に変えていく必要があります。
AI FinOpsについて、Vol.01では、AIのコストが設計判断から生まれることを書きました。Vol.02では、モデル選択、人の介入、並列度、知識基盤という四つの設計を見ました。
AIのコストは、モデルの価格だけで決まるものではありません。 モデルの使い分け、人が判断するポイント、Agentの並列化、知識基盤への投資。 品質を落とさず、AIを経済的に使い続けるための「4つの設計」を考えます。
AIを開発の現場で使い続けるために、今考えるべきこと
AI-Agent（以下、Agent）が要件定義のたたき台をつくり、コードを書き、テストまで回す。人が直接手を動かす仕事が減るにつれ、「プロジェクトマネジメントも必要なくなるのではないか」という見方が出てきた。だが、私たちは逆だと考えている。AI駆動開発の時代には、PMの重要性はむしろ高まる。ただし、従来のやり方をそのまま続ければよいわけではない。管理する対象、関係者、タスクの分け方、QCD＋Rの評価軸、プロジェクトの進め方、そしてPMに必要な力まで、Agentがチームに加わった現実に合わせて見直す必要がある。