「AIと協働して書いた35万字の書籍」が示す未来とは。広木大地氏が考える“AI時代のエンジニアの生存戦略”

AIの発展によって、エンジニアリングやソフトウェアのあり方はどのように変わっていくのか――2025年11月に刊行された『AIエージェント 人類と協働する機械』（リックテレコム社）は、その問いに正面から向き合った一冊。著者は『エンジニアリング組織論への招待』（技術評論社）を手掛けた広木大地氏です。

約35万字という大ボリュームの書籍ながら、執筆期間は1か月強。実は、著者自身がタイプした文章が1行もない“AIによって書かれた本”であり、そのワークフローの詳細は巻末の付録にもまとめられています。

「『AIエージェントとの協働』をテーマとする書籍を、AIエージェントとの協働によって書き上げる」という実験的な取り組みの背景には、本書が提唱する「知識創造するソフトウェア」が、すでに実装可能な概念であることを証明するねらいがあったといいます。

また、広木氏は本書を書きながら「自分は固定観念に縛られていないか」「本当にあるべき問題解決とは何か」と問い直しつづけていたとのこと。

AIが進化しつづけているなかで現在のエンジニアのあり方に固執していると、最終的には“Issueチケットを見てコピー＆ペーストし、AIにタスク内容を伝えるだけの作業伝達係”になってしまうのではないか、と警鐘を鳴らします。

では、広木氏が考える「AI時代におけるエンジニアリング像／ソフトウェア像」とはどのようなものなのか。いま、エンジニアに求められる姿勢とは何なのか。本書の制作プロセスの裏側とともに、同氏が見据えるソフトウェア開発の明日について伺いました。

• keyboard_arrow_down 「AIエージェントによる書籍執筆」という証明
• keyboard_arrow_down 「AIによる知識創造」から生まれる新たなソフトウェア領域
• keyboard_arrow_down AIにできない仕事はない。だが、AIと人間の競争も起こらない
• keyboard_arrow_down “エンジニアリングの固定観念”を捨てよう

――『AIエージェント 人類と協働する機械』は、AIについての解説をAIで書き、その制作手法についても掲載するというメタ的な構造を持った本です。なぜこのようなつくりになったのでしょうか？

広木：本書を手にした読者に「この本に書かれているのは遠い未来の話だ」と思われてしまうと、私の伝えたいメッセージが伝わらないので、何らかの形で近い将来の話だと証明しなければいけないと思っていました。それで「この本自体が、本書のテーマである“知識創造するソフトウェア”によって書かれている」と明かすことには意味があるのでは、と。

そもそも私は、シンギュラリティやAGIの到来といった“究極論”に対して「そうした議論にはプラグマティックな価値があるのだろうか」という疑問を持っています。面白いかもしれないけれど、いたずらに人々を悩ませてしまう側面があり、問題解決のヒントにならないのではないか、と。

例えば、スマートフォンの黎明期には「デバイスはどんどん小さくなっていく」「脳に埋め込めるようになる」といった予測もありましたが、実際にはむしろ画面は大きくなっていきました。

実際に経済的利益を得るのは、100年たたないと実現しないような技術に挑戦する人ではなく、「いまの技術でギリギリできること」を実現したプレイヤーです。「AIの進化がこのまま続くと、人間は働かなくなる」というような“究極論”よりも、いま自分がどう動いて何をするべきか、という問題にフォーカスすべきなのでは、と思っています。

――AIエージェントを使った書籍執筆は、どのように進めていったのでしょうか？

広木：制作フロー全体を設計し、さまざまなAIエージェントをアレンジして「君の作業はこれ」「君の作業はあれ」という風に役割分担していきました。AIエージェントの組織づくりをするようなイメージですね。

そうすると制作期間が短くなり、“本の設計図”を書いている段階で、ほとんどそれに即したものが出来上がってしまいます。なので、そこからは「本当はこういうことを言いたい」「こういうところを表現したい」と磨き込んでいきました。

ニュアンスとしては、1本の木から彫刻を削り出していく作業に近いですね。まず荒く切り、彫刻刀で彫りながら「ここが鼻かな」「そこは目かな」と形をつくっていき、その後、ヤスリをかけていきます。次第にヤスリの番号が上がって目が細かくなっていき、最終的にきれいな彫刻が完成する、という感じです。

エージェントごとの役割を設計し、組織構築のようなイメージで仕事をすること。それから、全体設計をしてから磨き上げていく「削り出し型」のプロセスをとること。この2点が、AIと協働しやすくしていくための考え方だと感じましたね。

――「書くこと」に対してのイメージがだいぶ変わりますね。一般的には、執筆とはそもそも「ひとりで行うもの」と捉える向きがあるのでは。

広木：AIエージェントとの協働は、映画づくりにも例えられるかもしれません。

映画はアートディレクターやプロデューサーなど、多くのプロフェッショナルが関わって一つの作品が完成します 。そこでは、個々のプロがバラバラに個性を出すのではなく、監督が全体を束ね、指示を出すことで面白い作品が生まれ、クリエイティビティが宿ります。

そのように「多くのプロを束ねて作品を生み出す」という制作プロセスが、AIによって低コスト化、民主化されたのです。本書の執筆には50万〜60万円分のトークンを使いましたが、人間に発注したら1000万円近くかかるのではないでしょうか。

――“本の設計図”となる、書きたいテーマ探しやネタ集めはどのように行ったのでしょうか？

広木： 本書の素材には、過去のプレゼンテーション資料や登壇時の文字起こし、それから、会議での私の発言をもとにインサイトを抽出してくれる独自のAIアシスタント 「しらせ君」がまとめた議事録などを活用しました 。

しらせ君は、「何を書くべきか」「何を書きたかったのか」を発見するプロセスそのものを自動化したような機能を持つツールで、NewsPicksでの連載にも活用しています。私が1on1などで話した内容から、しらせ君が知見を拾い上げてきて「これ、面白いので記事にしませんか？」と提案してくれる仕組みですね。

――書くべき知見やメッセージを生みだす工程も、ある種の協働作業になっているんですね。

広木：私は「自分は何を伝えたいのか」「どういう伝え方が適切なのか」といったことは、誰かからの質問、指摘といった外部刺激に対して答える過程で初めて見えてくるものだ、という感覚があります。

知見というものもそういった会話サイクルの中で、暗黙知が形式知に変わっていくようなプロセスをへて生まれるものだと思います。

――AIエージェントが登場したことで、エンジニアの仕事やソフトウェアのあり方はどう変わると考えていますか？

広木：「ソフトウェアエンジニアの仕事が今後どう変わるか」を考えるとき、私は「技術が進化して開発が簡単になればなるほどソフトウェアの適用領域が広がり、結果としてより多くのエンジニアが必要になる」という傾向に注目しています。
これは経済学で「ジェボンズのパラドックス（技術の効率化が進むとかえって資源の消費量が増える現象）」と呼ばれるもので、私たちの業界でもまさにこの需給の物語が繰り返されてきました 。
ここ20〜30年の業務システムの歴史を振り返ると、ソフトウェアは System of Record（SoR）、System of Engagement（SoE）、そして System of Insight（SoI） へと発展していきました。

最初のSoR は、企業の帳簿や帳票管理などの「記憶」をソフトウェアに代行させる段階です。例えば居酒屋では、ホールスタッフとキッチンスタッフのあいだで注文情報を連携することでメニューの提供を管理しています。このように複数人で共有すべき記憶をシステム化したのが始まりでした 。

次のSoEは、「接客」に相当する領域です。お客様からの注文受付や質問への回答、情報のデリバリーなど、顧客とのつながり（エンゲージメント）を作る部分がデジタル化されました。

顧客接点がデジタル化されると、そこから得られたデータから「洞察」を得て、顧客に対して「この商品がおすすめです」とレコメンドするようなニーズが生まれます。これがここ数年で広がったSoIです。

このようにソフトウェアの適用領域が拡張するたびに、インフラエンジニア、アプリ開発者、データサイエンティストといった新たな役割が必要とされ、エンジニアの需要は拡大し続けてきたのです。

――では、SoR、SoE、SoIのさらにその先。アフターAIのソフトウェアはどのような領域へ拡張していくのでしょうか？

広木：企業の仕事を日々の運営（Run）、新しい企画やサービスを生み出す（Grow）、そして企業自体の形を変える変革（Transform）の3段階に分けて考えてみましょう。

SoR、SoE、SoIはいずれもRunの領域に属します。これからのシステムは「Grow」の領域へと拡張していくと考えています。

日々の運営のなかでインサイトを得て改善していくこと、ユーザーに新しい価値を提案していくこと。ここには、SECIモデル（※）で説明される、暗黙知と形式知を相互に変換しながら新しい知識を生み出していく「知識創造」のプロセスが深く関わっています。

※SECI（セキ）モデル：経営学者の野中郁次郎氏らが提唱した知識創造理論。個人の持つ「暗黙知」と、言語化された「形式知」が、共同化・表出化・連結化・内面化の4つのプロセスを経て変換され、新たな知識が生み出されるとするモデル。

―― 「知識創造」のプロセスとは、具体的にどのようなものでしょうか？

広木： 先ほどお話しした、しらせ君を使った記事や書籍づくりが一例です。

――1on1などでの会話から生まれた知見を、AIによって拾い上げる、という。

広木：プロダクト開発や営業の現場でも、ユーザーと会話を重ねるなかで、相手の言葉そのものではなく、その奥にある「本当の課題」が見えてくることがあります。

これまでは、そうした会話から生まれる情報はその場限りのものとして消えてしまうか、個人の頭の中に閉じ込められていました。システムにサポートされていない、いわば「捨てられていた資源」だったのです。

しかし、過去の膨大な議事録や会話ログから知見をすくい上げるプロセスを、AIを使ってシステム化すれば、企業活動のより多くが自動化できるようになり、ひいてはそれがクリエイティビティを生み出すことにつながるのではないか、と考えています。

――「知識創造」や「SECIモデル」は、一般的には組織論の文脈で使われる言葉です。それをあえてソフトウェア開発の文脈に持ち込んだ意図はなんでしょうか？

広木：前著『エンジニアリング組織論への招待』を執筆した頃から、私は「仕事をソフトウェアがやるのか、それとも人間がやるのかは、実は大きな違いがないのでは」という問いにフォーカスしていました。

ソフトウェアアーキテクチャと組織論とでは、気にするべきポイントが驚くほど似通っています。情報の全体を処理しなくていいように役割分担したり、「あなたの役割はこれだよ」と役割を限定したりしながら問題解決していくという構造は変わりません。

従来はソフトウェアの言葉に落としていくか、人間の言葉に落としていくかという違いがありました。しかし、自然言語で指示できるAIの登場によって、ソフトウェアアーキテクチャと組織論の類似性はより理解しやすい形に変わったのではないでしょうか。

―― 「AIにはできない仕事／人間にしかできない仕事」という議論がよくありますが、広木さんはAIと人間の違いをどう捉えていますか？

広木：「人間に残された仕事」「究極的にAIにできない仕事」といった考え方をするのは、あまり得策ではないと思っています。“哲学的思考”としてはそういう議論もあり得るかもしれませんが、「これはAIにはできない」と言われていたことが、瞬く間にできるようになっているのが現状です。

人間が脳という唯物論的な仕組みで動いているのであれば、人間にその仕組みを作り出せない理由はないはずです。「人間にできて、コンピューターにできないこと」は原理的にないと思います。

AIと人間の違いは能力ではなく、人間には法的に認められた権利があるという点ではないでしょうか。消費の主体や意思の主体というのは私たちしかありえません。“究極論”として、100年後の世界ではロボットにも人権のようなものが認められている可能性も考えられますが、それは今ではありません。

AIと人間とのあいだにこういった社会的な区分がある以上、「AI vs 人間」の競争が起こることはありません。あくまで「人間 vs 人間」のまま、どれだけ効率よくAIを使って価値を創造できるかという競争に帰着すると思います。

―― 最後に。AIとの協働が進んでいくなかで、エンジニアが取り組むべきことはなんでしょうか？

広木：多くのエンジニアは、AIを使役するエンジニアリングマネージャーへとシフトしていく必要があります。プレイヤーとして問題解決をするという今のあり方から、全体をアレンジして問題の根本構造を解決していくという役割になるからです。

そのために、これまで培ってきたキャリア、考え方といったものをアンラーニングするタイミングが来ていると感じています。私自身、この本を書きながら「今まで当たり前だと思ってきたことに縛られていないか」「本当にあるべき問題解決とは何なのか」と問い直していました。そして、いまも考えつづけています。

というのも、これまでの働き方を続けていると、エンジニアは“Issueチケットを見てコピー＆ペーストし、AIにタスク内容を伝えるだけの作業伝達係”になってしまうんですよね。

そうならないために重要なのが、働き手が能動的に仕事のタスク・関係。認知を自由に再設計する「ジョブ・クラフティング」という考え方です。「エンジニアだからこうしなくてはいけない」と固定観念に縛られるのではなく、「今までフロントエンドしか書いていなかったけれどバックエンドを書いてもいい」「必要があれば営業のような、開発以外の仕事をやってもいい」。そんな風に、自分の仕事の範囲を広げていくことが重要です。

AIによって、よりクリエイティブな問題解決に取り組める可能性も生まれています。レビューが負担なら「レビューの完全自動化」に取り組んでいいし、そもそもissueを解決していくというプロセス自体を手放すために「どうしたら自動化できるか」「そもそもissueが発生しない構造はつくれるか」と考えてもいいのです。

今までのやり方や常識にとらわれずに、仕事を再設計していくこと。今後数年間は、それが楽しい仕事につながっていくと思います。

取材・執筆：川島 昌樹