AI時代のDependency Injection

AIにも人にも優しい文書とは

Transcript

1. AI 時代の Dependency Injection ～AIにも人にも優しい文書とは～ Yoichi Imai PHPerKaigi mini #5 @ 2026-09-17
2. 自己紹介 Yoichi Imai アプリケーションエンジニア フロントエンドとデータベースが主戦場 Web 2
3. 今日話すこと のうれしさと怖さ DI / IoC の話 AI にも人にも読める文書と、その使い方 skill 3
4. skill 、便利ですよね メリット AI への指示をまとめておける デメリット 実行が非決定的 同じ指示でも、結果が同じとは限らない 知識と処理の境界が見えにくい skill やモデルを変えたときの影響を追いにくい 4
5. この怖さ見たことないですか？ 巨大フレームワークに密結合したアプリケーション ビジネスロジックが実行環境を直接知っている 必要な機能を自分で呼び出している 結果として フレームワークの変化の影響を受けやすい 交換しにくく、単体で理解・テストしにくい ※ 非決定性は違っても、依存先が見えにくいところは似ている 5
6. 歴史は密結合にどう対処したか → Dependency Injection / Inversion of Control ビジネスロジックをフレームワークから切り離す 依存するものは注入してもらう 交換しやすく単体で理解・テストしやすくする final class OrderService { public function __construct(private PaymentGateway $gateway) {} } 6
7. AI にも通じるところがあるのでは？ 密結合な姿 skill が「プロジェクトの知識」と「処理」をすべて持つ 書き方次第ではある 制御を反転した姿（IoC） プロジェクトの文書が知識の主体になる skill は文書を読み、作業へつなぐ AI の非決定性は消えないが、モデルに依存する知識と処理の範囲は小 さくできる 7
8. アプリケーションのDIとの対比 アプリケーション を使うプロジェクト POPO/POCO/POJO プロジェクト文書 DI フレームワーク 文書と作業をつなぐskill 文書は特定のAIに依存しない→"Plain Old Document” AI 8
9. 文書の例1: ADR (Architecture Decision Record) 何を決めたか/なぜそう決めたか/却下した選択肢とその理由/どこに 適用するか AI に正解だけでなく判断の文脈も伝える 未来の開発者にも同じ文脈を残す 9
10. 文書の例2：コーディング規約 だけへの命令 「◦◦記法を使って実装してください」 プロジェクトの決まりごと 「このプロジェクトでは、△△には◦◦記法を用いる」 命令ではなくプロジェクトの話として書くことで、人が読んでも使え る。 AI 10
11. skill の例：ADRをチェックする はskillでスパイスのように活用する。 プロジェクトの判断基準はskillに書かない skill は差分収集・文書参照・報告をつなぐ 人も同じADRを読んで判断できる skill 11
12. 活用のためのヒント 宣言的にする 決定的に処理できる部分はそもそも通常のツール linter / formatter / AST 操作 文書をどう書くかは自由 人とAIが同じようにたどれる文書構造 構造化の選択肢：OKF（Open Knowledge Format） 12
13. まとめ は巨大構造に依存した処理の実装方式 プレーンな文書ならAIに依存しない プレーンな文書を活用して巨大構造への依存を減らしたい skill 13