AI開発の精度を決める「4つの入力」

プロジェクト固有のドキュメント
論理的判断
ドメイン知識
既存の成果物
＋
実践知のAI間共有

Transcript

1. AI開発の精度を決める 「4つの入力」 復活のY〜とりあえずモバイル開発についてワイワイ語り合おう〜 2026/2/27 1
2. 自己紹介 名前：k2moons / BlueEventHorizon 仕事：iOSアプリエンジニア X : k2_moons Github : BlueEventHorizon 好きなエディタ： Xcode 好きな生成AI： Claude Code 2
3. AIの出力精度 AIを使った開発プロセスで、なぜか精度が出ない プロジェクトのアーキテクチャルールに違反している 設計書と実装のズレを指摘してくれない 既存コードとの一貫性を見てくれない 3
4. AIの出力精度を決める4つの入力 4
5. 入力1：プロジェクト固有のドキュメント 要件定義書 設計書 コーディングルール など、そのプロジェクト特有の文書 5
6. 入力2：論理的判断 矛盾検出 整合性チェック- 合理性評価 という推論能力 6
7. 入力3：ドメイン知識 特定分野の専門知識 SwiftConcurrencyのactor isolation メモリ管理のベストプラクティス XCTestの設計パターン など 7
8. 入力4：既存の成果物 プロジェクト内で既に存在する実装コードやテスト 8
9. 入力の性質 入力 出所 AIへの届け方 1. プロジェクト 固有文書 人間が用意する（固定） 適切に参照させる必要がある 2. 論理的判断 AIが元来持っている 常に利用可能 3. ドメイン知識 AIが元来持っている 手放しで信頼できないが、常 に利用可能 4. 既存の成果物 プロジェクトに蓄積される （増える） 適切に参照させる必要がある 9
10. 入力1と入力4の問題 情報量が膨大 iOSプロジェクトでは、ドキュメントは数十〜数百ファイル コードはさらに巨大！！ ならば大容量コンテキストに全部入れればいい？ 10
11. Attention Budget（注意予算） コンテキスト内のトークン数が増えるほど、1つの情報に割り当て られる注意の重みが相対的に薄まります。 コンテキストは、収穫逓減を伴う有限のリソースとして扱わな ければならない “ “ 11
12. "Context Rot"（コンテキスト腐敗） コンテキストに詰め込むトークンが増えるほど、情報の検索精度が下がる 特に中盤に置かれた情報が見落とされやすい 満足化行動（Satisficing） 「関連ドキュメントを探して」と指示しても、1〜2個見つけた時点で探索を止 めてしまう なぜ生成AIは「ドキュメントを読んで」と言っても読まないのか？ 参照 12
13. 問題へのアプローチ 1.プロジェクト固有文書 13
14. RAG（Retrieval-Augmented Generation） 1. チャンキング（分割） ドキュメントを一定サイズの断片に分割 2. 埋め込み（Embedding） 各チャンクを埋め込みモデル（OpenAI Embeddingsなど）でベク トルに変換します 3. 検索・取得（Retrieval） クエリも同様にベクトル化し、ベクトルDB内の全チャンクと類似度 を計算。最も近いチャンクだけをAIに渡します。 14
15. RAGの問題 RAGの本格的な実装は手間 ベクトルDBの構築・運用、チャンキング戦略の設計 埋め込みモデルの選定と調整 検索精度が低いと、不完全なコンテキストをAIに渡してしまい逆 効果になる 15
16. 問題へのアプローチ 4. 既存の成果物 16
17. Serena LSP（Language Server Protocol）を活用してコードをシンボ ルレベルで解析 MCPサーバーとしてAIに構造的な情報を提供 ただし、iOSアプリ開発で一般的な .xcodeproj 形式のプロジェク トでは、SerenaのSwift解析は大幅に制限されます 17
18. SerenaがSwiftに使うLSPサーバーはAppleのsourcekit-lsp sourcekit-lspはSwiftPMパッケージおよびcompile_commands.jsonを持つ プロジェクトのみ対応 .xcodeprojは非対応（2019年にSwift Forumsで要望が出て以来、長年の 未解決問題） .xcodeprojではLSPが正常に起動できないため、Serenaのシンボルレベルの 操作が機能しない find_symbol（シンボル検索） find_referencing_symbols（参照箇所の検索） get_symbols_overview（シンボル一覧の取得） replace_symbol_body（シンボル単位の編集） 18
19. 独自のアプローチ 入力1を解決 19
20. DocAdvisor 事前準備： 全ドキュメント → ToC（YAML）を自動生成 各ファイルの目的・キーワード・適用タスクを抽出 問い合わせ時： サブエージェントがToCを検索 関連するファイルだけを特定・取得 20
21. 独自のアプローチ 入力4を解決 21
22. Swift-Selena MCP接続 Serenaと同じくコード構造解析のアプローチを、Swift固有の言 語機能に特化して実装 LSPが（正常に）動作しない場合も、class検索、extension検索 などが可能 22
23. シンボル一覧・定義箇所（クラス、構造体、関数など） 型継承階層（スーパークラス・サブクラス・適合型） プロトコル適合（UITableViewDelegate、ObservableObject など） SwiftUIのProperty Wrapper（@State、@Binding、 @ObservedObjectなど） XCTestおよびSwift Testingのテストケース検出 23
24. 第5の入力 ?? 第5の入力は、設計書やコードには残りにくい実践知 「この設計ならここで詰まりやすい」 「この順序で進めると事故が減る」 24
25. 会話から実践知を抽出する Claude Code SKILL ユーザーとの会話を、保存すべき内容を要約する 会話から実行可能な手順を生成する プロジェクト固有の部分は、具体例ではなく抽象度を上げる 25
26. 経験を自動永続化する claude-mem - GitHub Claude Codeの実行過程を観測、保存 検索可能な記憶として再利用 利用 searchで「どんな記録があるか」を一覧 timelineで前後の流れを確認 get_observationsで、本当に必要な記録だけを詳しく読む 26
27. 複数AIで知見を共有する AIや単一プロジェクトに閉じない共有資産 知見が時間軸とプロジェクト境界を越えて接続され、次の開発で再 利用できる 27
28. A2A エージェント同士の相互運用を目的にしたオープンプロトコル 異なる実装・異なるベンダー間でも連携できる 異なる実装のエージェント同士を容易につなげられる 接続先が増えるほど信頼境界は広がるため、認証・認可・監査・ データ最小化などが課題 28
29. まとめ AI開発には、品質の高い4つの入力があるべきです。 そしてもう既に、第5の入力を実現する仕組みを実現する世界が 来ています。 ただし、これらの入力の品質を担保するのは、あくまで人間では ないかと考えています。 29
30. 参考 DocAdvisor - GitHub Swift-Selena - GitHub claude-mem - GitHub A2A Protocol - 公式サイト A2A Protocol - GitHub OpenAI Agents SDK / Handoffs Anthropic Claude Code / Subagents Anthropic Applied AI Team (2025). "Effective context engineering for AI agents" Liu, N. F., et al. (2023). "Lost in the Middle: How Language Models Use Long Contexts" 30