Archive of posts from 2026-9

出典：Addy Osmani「Software Factories, Light and Dark」

1. 半世紀以上前の夢が現実になるとき

1968年、計算機科学者のBob Bemerは論文「The economics of program production」で、ソフトウェアファクトリーという構想を提示しました。開発を個人の職人芸から、自動車部品をプレスするように反復可能で、工程を計測できる生産プロセスへと変えるものです。それから半世紀以上、アイデアを「型」に流し込むことの難しさもあり、この構想は一部の例外を除いて十分な成果を上げられませんでした。

しかし今、AIエージェントの台頭により、この古い夢が現実味を帯びています。「コードを書くこと」から「コードを書く工場を動かすこと」へと、開発の仕事の単位が変わりつつあるのです。

2. ループ、ハーネス、ファクトリーの3階層

Osmaniは、HumanLayerの共同創業者であるDex HorthyがAI Engineer World’s Fairで行った講演を紹介しながら、ソフトウェア工場を「ループ」「ハーネス」「ファクトリー」という3つの階層で整理しています。

• ループ：エージェントが「文脈収集、アクション、結果確認」を、所定の条件を満たすまで繰り返す最小の作業単位です。
• ハーネス：ループを囲む環境と制約です。
  サンドボックス、利用可能なツール、実行をまたいで維持されるメモリ、そして「完了」を判定するゲートを含みます。
• ファクトリー：ハーネスに包まれた複数のループがワークキューから課題を取り出し、変更をレビューゲート経由で本番環境へと送り出す仕組みです。

Osmaniは、この構造を「ループで構成された組織図」にたとえています。エンジニアの仕事の重心は、個別のコード修正から、ループやハーネス、それらの間の流れの設計へと移ります。エージェントに一回ずつ指示を与える作業を、指示と検証を繰り返すシステムの構築に置き換えるのです。

3. ダークファクトリーと理解負債

製造業には、照明を必要としないロボットが生産を担う無人工場があります。こうした工場はダークファクトリーと呼ばれます。原文では、日本のファナックが2001年から稼働させている工場や、中国のXiaomiが2024年に開設した工場が例として挙げられています。

ソフトウェアにおける「ダークファクトリー」とは、人間が生成されたコードを読まず、機械による検証だけでデプロイする仕組みを指します。人間のレビューを省けば、短期的には開発が大幅に速くなったように感じられるでしょう。しかし、コードが増える一方で、人間の理解が追いつかなくなります。この隔たりが広がることを理解負債（comprehension debt）と呼びます。

週末の趣味のプロジェクトであれば、コードの詳細を読まずに生成AIとやり取りするバイブコーディングで、目的を達成できるかもしれません。しかし、10年以上続くエンタープライズシステムを業務で維持する現場では、コードを理解せずに変更し続けると、問題の原因や影響範囲を追うことが難しくなります。テストが通っていても、中身を誰も理解していないシステムには、こうした保守上のリスクが残ります。

4. なぜ生成速度を上げても開発は速くならないのか

AIによってコードを生成しやすくなっても、開発プロセス全体が同じだけ速くなるとは限りません。人間の判断を伴うレビューゲートは、生成と同じようには処理能力を増やせないからです。

ここで問題になるのが、生成と検証の処理能力の差です。

• 生成：AIによって、大量の変更を短時間で作成できます。
• 検証：人間がレビューに使える時間や注意には限りがあります。

生成をいくら速めても、検証が追いつかなければ、未処理のプルリクエスト（PR）が積み上がります。Osmaniは、後段の検証能力に合わせて前段の生成を制御する考え方を、バックプレッシャー（背圧）として説明しています。ループに与える自律性も、低コストで信頼性高く検証できる範囲に収める必要があります。信頼できる検証の仕組みがないまま生成量を増やすと、不具合の流入も防ぎにくくなります。

5. グラフによるエージェントの制御

AIエージェントに自由に手順を選ばせるループは、複雑な既存のコードベース（ブラウンフィールド）で、処理が長引くほど方針を見失いやすくなります。Horthyは、エージェントが扱う範囲を3〜10ステップ程度、多くても20ステップ程度に絞ることを目安として示しています。蓄積する文脈を抑えて信頼性を保つための指針であり、特定のステップ数を超えれば必ず失敗するという限界を示したものではありません。

この対策の一つが、ループをあらかじめ定めたワークフローに組み込む方法です。各ステップをノード、ステップ間の遷移条件をエッジとして表すグラフで、処理の流れを明示的に定義します。

エージェントは各ノードの中で判断しますが、次に進む条件や必須の検証は、外側のプログラムが制御します。ソフトウェアをフローチャートで表してきたように、エージェントにも処理の流れを定める考え方です。

このアプローチでは、決定論的なコードを骨格とし、要所にLLMの処理を組み込みます。型やテスト、明確なコンポーネント境界といった従来の設計手法も、モデルの誤りを検出し、影響を抑える手段になります。

6. アウターループを担うエンジニア

ファクトリーが稼働し始めても、エンジニアの役割が消えるわけではありません。自動化する仕組みを設計し、その成果を確かめる役割が増していきます。

• インナーループ：エージェントが担う、バグの調査、調査結果の報告、修正の実装、テストの実行などの作業です。
• アウターループ：人間が担う、解決方針や実装の妥当性の判断、アーキテクチャの決定、変更の承認、結果に対する責任の引き受けです。

人間は、実装前の設計に加え、エージェントが提示する根拠（コードの差分、テスト結果、ログ）を基に判断します。たとえば、リント違反や、必須であるべきプロパティを省略可能にしている定義の修正は、検証方法が確立していれば、修正から小さなPRの作成までを自動化できます。ただし、PRの作成と、本番への反映までを全自動にすることは別の判断です。認証システム、課金処理、公開APIの契約など、誤りの影響が大きい領域では、人間が設計段階から判断に加わり、変更内容を確認する必要があります。

ライトスイッチをどこに置くか

生成AI時代のソフトウェア開発では、どこまでを全自動にし、どこに人間の判断を残すかが設計上の課題になります。人間の判断が必要な箇所に明かりを残すのが、ライトファクトリーという考え方です。

すべてを自動化してコードを読まなくなれば理解負債が増え、すべてを人間が細かく確認すればレビューが滞ります。エンジニアには、誤りの影響と検証のしやすさを見極め、ループごとに自動化の範囲を決める仕事が求められます。

事実としては悲惨で悲しいことではあるが、映画としては”調整”が進まないのをひたすら待つだけ。観客も含めて無力であることを突きつけられるものだった。

全日満席だった。すごいね。内容としては悲惨だけど、映画としては平凡かなあ。カウンセリングを受けるときに嫌な質問をされるのだが、それが明確な治療法じゃなかったと医者が告白してどっちらけ。

スパイダーマンをちゃんと見てないので、ゼンデイヤを認識してなかったが、かなり人気なんですね。で、そのゼンデイヤと同じく『オデュッセイア』に出演していたロバート・パティンソンが結婚するまでのお話。仲間内で「今までにやった最低なこと」を暴露し合おうという話になり、ゼンデイヤが暴露した内容が「いや、それは引くわ……」ってなってしまって、みんなの関係性がギクシャクするという流れ。過去は清算できるのか？っていうのがテーマっぽい。まあ、映画としてはいまいちだが、A24にしては面白かった。あと2人の演技はよかったです。

母親を早くに亡くし、父親に育てられたが、じゅうぶんに愛情を受けていないので自分を愛することができない主人公の女性が、Facebookで父親と同じ名前のおじさんと友達になり、父親的な愛情を受け、自分を取り戻していくという話。

映画としては非常によかったと思う。素晴らしいまである。が、主人公の性格的な欠点が目につくし、あえてぽっちゃりな女優さんを配置したところにも、なんかありそうな気がしてならない。愛を受けてないとこうなる、っていう解釈もできなくもないが、ちょっと一方的過ぎるかなあ。私は年齢的にお父さんのほうに同情してしまったよ。でも、監督自身の実体験というから、仕方ない。

監督が若くてYouTuberってことで話題らしいけど、死ぬほどつまんなかった。A24の悪いところを煮詰めた感じだった。1990年のシリコンバレーが舞台なので、バックルームズとはインターネットの比喩ではないか？とのことらしいけど、にしては描き方下手くそじゃないかなあ。

悪くない雰囲気だったが、最後あたりでグダっとしちゃったな。年数も合わないだろ。とはいえ、少女も、お姉ちゃんも、お母さんも、隣の店のあんちゃんも、みんなよかった。海外だと2025年にNetflixで公開って感じなんですかね。

• 3時間は長いよ
• 時代劇みたいなクライマックスが最高
• ノーランはCG嫌いで有名だが、絶対に使わないわけでない。なんだけど、決してうまいわけではないので、ルックに関しては、まあ、ねえ、という感じだった。
• 「ゼウスの掟」がテーマになっているので、これは先に調べておいたほうがいい
  • 藤村シシン先生のアトロクでの解説を聞くのがいちばんだろう。
    • なお、シシン先生のポストもある

• ゼウスの掟：
  • 見知らぬ人でももてなす
  • 身元や用件を聞くのはもてなしたあと（身分の違いでもてなしを変えない）
  • 客を追い返してはいけない
  • 帰りたい人を引き止めてはいけない
  • 客はもてなしの厚意を悪用してはいけない
• オデュッセウスは（ホメロス版とは違い）トロイの木馬作戦のことを悔やんでいる
  • これは「神への奉納物を悪用した」騙し討ちであり「ゼウスの掟が守られていない」と同義になっている
    • 言い換えれば「神への冒涜」であると同時に「人間同士の信頼の崩壊」を意味する
  • トロイア戦争以降、信頼関係が崩壊した世界になっている
    • そんな世界でも依然として掟を守っている
• 一度壊れた信頼は元には戻らない
  • オデュッセウスがどれだけ悔いても、すでに信頼の崩壊を取り消すことはできない
    • せめてオデュッセウスが世界から「退場」することで幕引きとする
      • このあたりがノーランのアダプテーション

Jaco Quistは『Backcasting for a sustainable future』において、独自の手法を提案している。

1. なぜバックキャスティングが必要なのか？

未来研究（Future Studies）では、未来を「ありそうな未来」「可能性のある未来」「望ましい未来」の3つの階層で捉える。バックキャスティングでは、既存の延長線上では到達し得ない「望ましい未来」を構想し、そこから逆算して現在のアクションを規定する。

2. バックキャスティングの歩み

バックキャスティングの概念は、1970年代にLovinsが提案した「バックワード・ルッキング分析」に端を発する。その後、Robinsonによって「エネルギー・バックキャスティング」として体系化され、政府主導の政策分析やシナリオの実行可能性、環境・社会的影響評価のためのツールとして発展した。

1990年代に入ると、スウェーデンやオランダを中心に、この手法は「持続可能性（サステナビリティ）」の領域へと拡大した。バックキャスティングが不可欠とされる背景には、現代社会が直面する「根深い問題（Persistent problems）」の存在がある。こうした問題が現代を「持続不可能」にしている原因なので、このまま何もしなければ解決されることはない。

近年では、「第2世代バックキャスティング（Second Generation Backcasting）」へと進化を遂げている。これは、単なる専門家による分析から、多様なステークホルダーが関与する「インタラクティブな社会研究」への転換を意味する。

3. 主要な4つのバックキャスティング手法

バックキャスティングの実践においては、目的や文脈に応じて最適化された複数のアプローチが存在する。以下に主要な4つの手法を比較分析する。

Robinsonのアプローチ

• 前提: 規範的かつデザイン指向。実行可能性と政策的含意に重点を置く。基準は分析の外部から設定される。
• ステップ: 目的決定 → 目標・制約の設定 → システム記述 → シナリオ構築 → 影響分析。
  • 合意形成よりも、論理的なモデル化と政策分析を重視する。

The Natural Step (TNS)

• 前提: 企業の戦略的計画に特化。以下の「4つの持続可能性原則」を絶対的な前提条件とする。
  1. 資源利用（地殻からの物質）の抑制
  2. 排出（社会によって生成された物質）の抑制
  3. 生物多様性とエコシステムの物理的維持
  4. 資源の公平かつ効率的な利用（公平性）
• ステップ: 持続可能性基準の定義 → 現状分析 → 未来ビジョンの想起 → 戦略策定。
  • 従業員の参加と創造性を引き出すプロセスを重視。

STD（持続可能な技術開発）プログラム

• 前提: 40〜50年後の将来を見据え、環境負荷を「ファクター20（20分の1）」に削減することを目指す。技術と社会の「共進化」を前提とする。
• ステップ: 戦略的問題の方向付け → 将来ビジョンの共創 → 代替案のバックキャスティング分析 → R&Dアジェンダの策定 → 実装とフォローアップ。

SusHouseプロジェクト

• 前提: 持続可能な家庭機能（食、住、衣）に焦点を当てた国際プロジェクト。
• ステップ: 機能定義 → ステークホルダー分析 → 創造性ワークショップ → デザイン指向のシナリオ構築 → 消費者受容性・環境・経済性の多角的評価。

4. Quistが提案する5段階フレームワーク

Quistが提案する汎用的なフレームワークは、バックキャスティングを「社会実験」として捉え、多様な主体の関与を前提としている。

STEP 1：戦略的問題の方向付け (Strategic problem orientation)

• 解決すべき問題の範囲、機能、時間軸を明確に定義する。
• 参加者間で、持続可能性に関する規範的な前提条件（目標値など）の合意を形成する。

STEP 2：将来ビジョンの構築 (Develop future vision)

• 既存の制約を排除した「望ましい未来像」を創造的に描く。
• 多様なステークホルダーがビジョンを共創し、目指すべき「北極星」を共有する。

STEP 3：バックキャスティング分析 (Backcasting analysis)

• 将来ビジョンから現在を「振り返り」、実現に向けた複数の代替ルートを特定する。
• 現状とビジョンのギャップを埋めるために必要な技術的・社会的要素を構造的に分析する。

STEP 4：将来の代替案の精緻化とフォローアップ・アジェンダの策定 (Elaborate future alternative & define follow-up agenda)

• 特定された代替案を具体的なアクションアイテムへと落とし込む。
• 研究開発（R&D）アジェンダの策定、政策提言、および具体的な共同アクションプランをアウトプットする。

STEP 5：結果とアジェンダの定着、およびフォローアップの刺激 (Embed results and agenda & stimulate follow-up)

• 導き出されたビジョンやアジェンダを、参加組織の日常的なルーチンや意思決定プロセスへと組み込む（Embedding）。
• 構築されたネットワークを維持し、継続的なフォローアップ活動を刺激・管理する。

5. バックキャスティング・ツールキット：4つの武器

本フレームワークを有効に機能させるためには、以下の4つのメソッド・カテゴリーをステップを横断して統合的に活用することが不可欠である。これは、知識と価値観を融合させる「超学際的」な実践を支える武器である。

1. 参加型ツール (Participatory tools) ステークホルダーの対話と創造性を引き出す。ワークショップ、対話ツール、参加型シナリオ構築法など。
2. デザイン・ツール (Design tools) 将来シナリオの具体化や、新しいシステム・プロセスの設計を支える。システムデザイン、プロセスデザイン手法。
3. 分析ツール (Analytical tools) 客観的な評価を行う。環境評価（LCA等）、経済分析、消費者受容性調査、ステークホルダー分析など。
4. マネジメント・通信ツール (Management and communication tools) プロセス全体の管理とネットワークの維持。ステークホルダー・ネットワークの管理、結果の普及、プロセスデザイン。

6. まとめ：バックキャスティングがもたらす価値

バックキャスティングの真の価値は、単に美しい未来図を描くことにあるのではない。その本質は、以下の3つのダイナミクスを同時に引き起こすことにある。

1. 学習（Learning）: 参加者が互いの視点を知り、自身の思考枠組み（メンタルモデル）を根底からアップデートすること。
2. 合意形成（Congruence）: 異なる背景を持つ主体が、共通の方向性や問題定義に対して「一致（コングルエンス）」を見出すこと。
3. アクション（Action）: 壮大なビジョンを具体的な実行課題へと翻訳し、現実のネットワークの中で具体的な変化を開始すること。

専門的な分析（Inter-disciplinary）と、ステークホルダーの価値観や知識の統合（Trans-disciplinary）を両立させることで、バックキャスティングは持続可能な未来への実効性ある「変革のデザイン」を可能にするのである。