ハクソク

世界を動かす技術を、日本語で。

AIソフトウェア開発の未来

96日前原文(martinfowler.com)

概要

Thoughtworks Future of Software Development Retreat の主な議論点と業界への影響についてまとめる。 AI時代のソフトウェア開発 における課題と新しい実践、組織構造の変化を紹介。 LLMやAI技術 による専門性の変化とコスト、役割の再定義について考察。 セキュリティやプラットフォームの重要性、および多様性と対話の文化について言及。 コードヘルスやTDDの価値、AIフレンドリーな開発の実践的知見を共有。

Thoughtworks Future of Software Development Retreatの振り返り

  • Thoughtworks主催 のFuture of Software Development Retreat参加報告
  • 新たなAI開発マニフェスト 策定の場ではなく、現状の課題と展望の共有が主目的
  • イベント要約PDF は8つの主要テーマで議論を整理
    • 「厳密性の行方」「新しい中間的な作業カテゴリ」「技術基盤：言語・セマンティクス・OS」「人間側：役割・スキル・経験」など
  • AI支援開発 により従来の人間中心の開発手法や組織構造が機能不全に
  • 新たな実践や組織構造 は形成途上、成熟には至らず

AI時代の開発現場の実感

  • Annie Vellaの感想 ：AI導入やチーム再編の「正解」は未だ模索中
  • 不確実性が支配的 で、全員が手探り状態
  • 共通認識の形成 が最大の成果
  • 問いの共有 が今後の議論の出発点

AIの加速効果とリスク

  • AIは「加速装置」 として既存のプロセスを増幅
  • DORA 2025レポート ではAIの役割を「アンプリファイア」と定義
  • コード執筆速度向上 はボトルネック解消には直結せず、むしろ技術的負債の加速要因
  • 従来のベストプラクティス未整備 の場合、AI導入が負債増幅に

LLMがもたらす専門性の変化

  • LLM普及により フロントエンド・バックエンド専門家の役割縮小
  • Expert Generalistの台頭 や、LLMによるサイロ横断の可能性
  • LLMがサイロを回避するのか、解消するのか は今後の課題
  • LLM利用コスト の将来予測は不透明、コスト次第で使い方が大きく変化

ワークフローと開発プロセスの変化

  • 仕様主導型開発 （ウォーターフォール回帰）の懸念
  • LLMによる進化的設計 支援の効果はワークフロー次第
  • 小さな機能単位でのリリース の価値は変わらず、LLMはそのサイクルを加速

セキュリティとプラットフォームの重要性

  • AI導入に慎重な大企業 の姿勢（先端から四半期遅れで採用）
  • セキュリティは後回し になりがちだが、AI時代はプラットフォームの設計が鍵
  • AIベンダーの責任 と安全設計の必要性
  • 「バレットトレイン」的な安全かつ迅速な導入経路 の確立が重要

オープンスペース形式と多様性

  • Open Space形式 の議論による深い対話と多様性の尊重
  • 参加者全員が対等に議論 できる場の価値
  • Thoughtworksのカルチャー としての一体感と外部とのギャップ

AI普及による業界動向と心構え

  • Stephen O’Gradyの分析 ：AIはソフトウェア開発の民主化を推進
  • Grady Boochの見解 ：「AIは歴史的な抽象化の一歩」、冷静な受け止めを推奨
  • AIの不可逆性 と、メリット最大化・コスト最小化への取り組みの必要性

コードヘルスとAIフレンドリー開発

  • Adam Tornhillの研究 ：「AIフレンドリー」なコードはリファクタリング成功率が高い
  • 5,000プログラム・6種LLMでの大規模実験
  • ヘルシーなコードベース ではAIのパフォーマンスが向上
  • レガシーコードでのリスク増加、非線形な関係性が示唆

TDDとLLM活用の実践知

  • TDD（テスト駆動開発）の価値 をLLM活用現場で再認識
  • 明確なテストとTDDサイクル がLLM活用の成功要因
  • 最先端ユーザーからもTDD推奨の声 が多数

Hackerたちの意見

HNのタイトルはTFAの内容を反映してない気がするな。リンク先の記事[0]の方が合ってると思う。でも、ファウラーの記事は面白いよね。「すべてのコードは技術的負債だ」という考え方、いいと思うし、必要以上に増やすべきじゃないよね。ただ、負債自体が悪いわけじゃないことも忘れちゃいけない。住宅ローンで家を買うのも負債だけど、いろんな理由で良い選択になることもあるしね。 [0]: https://thenewstack.io/ai-velocity-debt-accelerator/

└

ここで紹介されてる「認知的負債」のアイデア、好きだな。特に「理解なしの速度は持続可能ではない」というフレーズが響く。

└

うん、あの編集されたタイトルはこの投稿には全然合ってない。問題は、実際のタイトルが「Fragments: February 18」っていうのもここには合わないってこと。だから、「Thoughtworksのソフトウェア開発の未来リトリートからの小ネタ」みたいな感じにしたらどうかな？（最初の文から取ったら、内容をうまく捉えてると思う。）

└

技術的負債って名前、全然間違ってるよ。「技術的負債」は負債というよりも株式に近い感じ。プロジェクトがうまくいかなければ、その「技術的負債」は問題にならなくなるし。

└

個人的にはそう思わないけど、混乱を避けるためにタイトルを変更したよ。

あの編集されたタイトル、なんなの？実際はThoughtworksのソフトウェア開発の未来に関するリトリートについての文章なんだけど。

└

私の意見では、そうは思わないけど、混乱を避けるためにタイトルを変えたよ。

LLMは専門的なスキルを食いつぶしている。LLM駆動のスキルがプラットフォームの使い方の詳細よりも重要になってくるから、専門のフロントエンドやバックエンド開発者の需要は減るだろうね。これがエキスパート・ジェネラリストの役割の認識を高めることにつながるのか？それとも、LLMがたくさんのコードを書く能力が、サイロを排除するんじゃなくて、周りをコードで囲むことになるのか？今のところ、これが一番面白い質問だと思う。LLMのおかげで、フロントエンド開発やオペレーション、自動化、UIデザインなんかで、もっと大きな挑戦を受け入れられるようになった。これが他の人にも上手くいけば、私たちの職業の形はどうなるんだろう？

└

自分も同じようになってきた。独自の実装に特化する代わりに、すべてをもっと完全に計画して、業界基準や他の開発者のベストプラクティスに基づいたスキルを書いている（もちろん、たくさんのアンチパターンも含めてね）。それ以来、作業フローは劇的に改善されたけど、これらの実装を適切にデバッグするスキルが育っていないんじゃないかと心配してる。スキルがほとんどの作業をやってくれたからね。

└

自分も同じような経験があるけど、結論は逆だな。過去6ヶ月間、俺のコードはすべてClaude CodeとGemini CLIで書かれてる。バックエンド、フロントエンド、インフラ、iOSのコードも書いたよ。キャリアの流れを考えると、数年前にはこれが不可能だった。だけど、技術的負債はすごく大きい。正直に言うと、これらの技術に対する理解は「専門家」レベルじゃない。経験豊富な開発者が俺のコードを見たら、ひどいもので再アーキテクチャが必要だと思うだろうね。動いてるから良いけど（それは素晴らしい！）、ソフトウェアエンジニアリングの面ではまだまだ足りない。

└

コードは急速に商品化していると思う。以前は、コード自体が価値のあるもので、MicrosoftのMS-DOSとIBMのPCハードウェアのような関係だった。それが長い間続いていた。FOSSのおかげで、再利用可能なコンポーネントを使うコストはほぼゼロになった。大規模なパブリッククラウドは、コードを実行するコストがほとんど無視できるほどになった。そして今、モデルプロバイダー（Anthropic、Google、OpenAI）のおかげで、コードを生産するコストは比較的小さい。コードの生産コストがほぼゼロに近づくと、周りのすべてを最適化し始める。今やコードは鋼鉄のような存在だ。自体としては少し価値があるけど、もう町の鍛冶屋に物を作ってもらう必要はない。まだ価値があるのは、何を作るべきか、いつ作るべきかを知る直感。それが我々の職業に残された「何か」なんだ。

└

それってただ階層が一つ上がっただけじゃない？10年前にはほとんどの開発者が機械語でコーディングすることを忘れてた。だって、知ってる必要がなかったからね。今は、ただ一段階上に進んでるだけだよ。

└

専門的なジェネラリストを、気にする価値のある規模で雇う会社なんてないよ。評価がめっちゃ難しいし、そもそもそういうパイプラインが存在しない。可愛い謎解きで採用しようとした大手ソフトウェア会社も、結局は文化に合ったスペシャリストを雇っただけ。専門的なジェネラリストは、詐欺師と区別するのもほぼ不可能だしね。だから、LLMと相性がいいんだよ。 ;)

LLMはトークンの補助金がなくなったら人間より安くなるの？今のところ、トークンの本当のコストがどれくらいか全然見えないし、数年後にどうなるかなんてもっと分からない。トークンをLLMにどれだけ送っても気にしないくらい安くなるかもしれないし、逆に高くなってすごく気を使わなきゃいけなくなるかもしれない。ある程度の見当はついてるけど。Kimi K2は比較的高性能なオープンソースモデルで、Mac Studioのペアで24トークン/秒で動かしてる人もいる。これには2万ドルかかるけど、1KW未満の電力で動くから、そこで使う0.8-0.15ドルは開発者に比べたら微々たるものだよね。これがローカルで動かすのに一番安いセットアップかもしれないけど、スケールで専用ハードウェアを使うとトークンのコストはずっと安くなるのはほぼ確実。つまり、ほぼ最前線のモデルが、（やや裕福な）ホビイストが手が届くコストで動いてるってこと。ハードウェアのコストがかなり下がるのは想像しにくいけど、トークンがかなり補助されてるのは間違いないと思うけど、これは誇張されてるかもね[1]。モデルのトレーニングはまだものすごく高いし、それは確かに補助されてるけど、たくさんの推論に対してそのコストを分散できるから、アイデアの高原に達してトレーニングを頻繁に行わなくなると、もっと楽になるよ。

└

ほぼ最前線のモデル Kimi K2は本当にほぼ最前線なの？少なくともエージェントハーネスで動かしたり、一般的なコーディングの質問には、かなり遠い気がする。ベンチマークがどう言ってるかは知ってるけど、いつも素晴らしいって言ってるし、最前線のモデルに近いって。でも、実際には他の人の印象はどうなんだろう？もしかしたら、私のプロンプトスタイルはGPTタイプのモデルに合ってるのかもしれないけど、私がやってるような普通のエンジニアリングの仕事には合ってない気がする。

└

「（やや裕福な）ホビイストが負担できるコスト」って、2万ドルは趣味に使うには結構な額だよね。多分、全てのホビイストの中でそれを負担できるのは10%未満、もしかしたら5%未満だと思う。

└

ホビイストにとって、そんなセットアップに2万ドル？「やや」を抜いても、世界的には1%未満の領域に入るよ。1kWの電力は、少なくとも俺には年間2千ドルかかるし、ずっと稼働するとは思ってないけど、安いサブスクリプションで年間100〜200ドルで済むなら無視できない金額だよね。

└

こんなに高くなくても大丈夫だよ。今なら、128GiBの統合RAMを搭載したAMD Ryzen Strix Halo（AI Max+ 395）マシンが約2500ドルで手に入る。Qwen3 Coder Nextで8ビット量子化した場合、約20トークン/秒、Minimax M2.5で3ビット量子化した場合は17トークン/秒が出る。これらのモデルは少し弱いけど、Claude SonnetからClaude Opus 4の範囲に入ってる。個人の趣味の予算内で、SOTAから6〜12ヶ月遅れてる感じだね。

└

他の人へのリマインダーだけど、2万ドルは一度きりのスタートアップコストで、年間2〜4千ドル（プラス電力）の償却が必要だよ。俺の周りでは、家族のジム会員費と同じくらいの金額だね。

└

確かDarioがAI推論の粗利益率は40%-50%だって言ってた気がする。

└

ひどい比較だね。LLMの推論は、実際のGPU/TPUでデータセンターでバッチ推論を行うよりも、単一ユーザーにとってはずっと高くつくよ。

└

ハードウェアコストがかなり下がるとは考えにくいよね。去年のハードウェアの状況に注意を払ってた？今週、2026年のディスクの供給を買い占めたみたいだよ。

└

もし彼らのエンジニアリングチームをK2と話す役員に置き換えたら、90%の会社は1年で倒産するだろうね…

FOMOを乗り越えよう：その部屋に入るとき、もっと進んでいる人たちから学べると思ってた。AIを大規模に導入する方法や、チームをそれに合わせて再構築する方法、どうやってうまく機能させるかを解明した人たちがいたんだ。ソフトウェア業界の一番鋭い頭脳がそのテーブルに座ってたけど、誰も全てを理解してるわけじゃない。そう言ってる人は、あなたの頭を混乱させようとしてるだけだよ。

└

「大規模にAIを導入する/組織を再構築する」レベルでは、確かにその通りだね。まだ誰も完全なプレイブックを持ってないし、持ってるって言ってる人は多分誇張してると思う。でも、プログラマーの視点から見ると、もう小さい部分ではかなり解決されてることが多いよ。作業を狭くして、元に戻せるようにして、制約を明確にして、検証を安く保つ（テスト、インバリアント、差分）ことで、エージェントは今でも信頼できる存在だよ。問題は「これがうまくいくのか？」じゃなくて、「リスクとエントロピーを増やさずに、どうやってこれを産業化するか？」ってことだね。この「FOMOなしの穏やかな導入、委任＋制約＋検証」については、ここにまとめたから、スレッドの参考になればいいなと思ってるよ。: https://thomasvilhena.com/2026/02/craftsmanship-coding-five-...

これが専門的なゼネラリストの役割の認識を高めることにつながるのかな？LLMは新しい分野やトピックで平均的になりやすいと思ってる。でも、LLMを最大限に活用するには専門知識が必要だよね。個人的には、LLMのおかげでソフトウェア開発が「勝つためにお金を払う」状態になったのか、逆にそうじゃなくなったのかに興味があるな。

確実に言えるのは、エージェントの未来はテスト駆動型だってこと。テストは基本的にエージェントが従って検証できる実行可能な仕様なんだ。しっかりしたテストがあれば、エージェントの出力は役に立つし、信頼できる。テストが薄かったり欠けてたりすると、エージェントはたくさんのコードを出荷するけど、微妙なバグをデバッグしたり修正したりするのにずっと時間がかかるんだよね。

└

うわ、今度はAIのAPIを設計しなきゃいけないのか。ロジックを通さずにエッジケースを考えなきゃいけないし、結局実装にガッチリ結びついたテストになっちゃうんだよな。

└

だから、HaskellやOCamlのような強く型付けされた言語と相性がいいと思うんだ。コンパイルしてビジネスロジックの単体テストを通るまでこれをやれって言うんだよね。JSONスキーマバリデーターみたいな検証ツールをもっと使うようになってる。エージェントに与えるガードレールや厳しいチェックが多ければ多いほど、パフォーマンスが良くなるんだ。

1980年代にソフトウェアの世界に入ったとき、データベースの人たちからは「オブジェクトの人」とか言われて、オブジェクトの人たちからは「データモデラー」ってバカにされたんだ。それ以来、「パターンの人」、「アジャイルの人」、「アーキテクチャの人」、「Javaの人」、「Rubyの人」、そして「反アーキテクトの人」って感じで、どんどん肩書きが増えていった。今じゃ、過去の人になったおじいちゃんとして、若い同僚たちの知的な血を吸って生き延びてる。美味しいよ。こんなレベルのエゴは、ソフトウェア業界でも他の業界でも見つからないと思う。リスペクト。

└

最初は記事の中で見つけられなくて混乱したけど、君が引用した部分を見つけたよ：https://martinfowler.com/articles/expert-generalist.html

└

「マイクロ・クソ野郎」のことを忘れてるね。少なくとも彼はアンクルボブではないけど、あまり遠くない。AIの前からダメだったよ。

マーチンの枠組み（リスクの階層化やTDDを規律として、プラットフォームを「新幹線」とする）は、私が見ていることと一致してる。プログラマーのレベルでのシフトも役立つよ：エージェントは、検証が安価な時に狭い範囲で可逆的な作業が得意なんだ。具体的には、ゴールデンテストの裏での小さなリファクタリング、契約テストの裏でのAPIアダプター、明確な不変条件を持った機械的なマイグレーションを考えてみて。暗黙の結合、あいまいな境界、弱いフィードバックループがあるコードベースでは早く失敗するし、既存のハイジーンを増幅しがち。だから、仕事はタイピングから制約を明示化して、迅速な検証を構築することに移るけど、人間は意味とリスクに対して責任を持つ。もし役立つなら、この「委任 + 制約 + 検証」の視点をここで広げたよ：https://thomasvilhena.com/2026/02/craftsmanship-coding-five-...

「我々が知っているソースコードが、一時的なアーティファクトになり、必要に応じて生成され、決して保存されないという、より過激な可能性もある。」この点については意見が分かれたね。ある人は、10年以内にソースコードが消えると考えていたし、他の人は、決定論的な検証には安定したアーティファクトが必要で、そのアーティファクトは呼び方に関わらず実質的にソースコードだと主張していた。ここで、実現方法が全く分からないけど、思いついた自由なアイデアがあるんだ。誰かもっと賢い人が来て、これが素晴らしいアイデアだと思って、盗んでくれることを願ってる。ぜひやってみてほしいし、うまくいくことを願ってるよ。アイデアは、何らかの基盤、例えば超パワーを持つASTのようなものを持って、これが真のコードになるってこと。実際にコンパイルされて実行されるものだよ。人間はこれを直接見ることはない。代わりに、このコードの表現を見て、異なる表現の間を切り替えることができるんだ。ここでは数学のトポロジーからアイデアを借りてるんだけど、ある形を一つの方法で見たら、別の形に変換できるべきだけど、同型的には全て同じなんだ。それによって、同じものを異なる視点で見たり、異なる角度から理解したり、より簡単に批評したり、メンテナンスしたりできるようになる。Geminiによれば、このアイデアは過去に既に試されたことがあるの？プロジェクショナルエディティング？意図的プログラミング？