AI駆動開発時代の メンタルモデル AIが「作る」なら、エンジニアの価値はどこにあるのか？ 2025.10 | Engineering Mindset in AI Era 1 / ©2025 Sun* Inc. | Daiki Miura 

自己紹介 三浦 大輝 Daiki Miura 🏢 現在の職務 株式会社Sun Asterisk / Backend Engineer - Creative&Engineering, Engineering Pros - Strategic Planning and Development, Strategic Technology 💻 略歴 文系大学卒業後、新卒で商社営業部に就職。独学でITエンジニアに転身し、 フリーランスにてフロントエンド開発を経験。 その後、受託ベンチャー企業でフロントエンド・バックエンドに加えPMOを 兼務しつつプロジェクトを推進。 Sun*へ参画後はバックエンドエンジニアとして開発実務を担当しつつ、組織 全体でのAI活用促進のための戦略策定と実行を推進する。 @backenddevcat @miup 1 / ©2025 Sun* Inc. | Daiki Miura 

今日お話しすること 1. なぜ今メンタルモデルのアップデートが必要か 2. AI駆動開発の3原則 3. コンテキストエンジニアリング 4. ドキュメント資産化 & 事例 個人最適の限界 / “使う”思考の頭打ち 最小限で十分な情報 / 高速試行ループ / 知識の資産化 何を｜いつ｜どう渡す ドキュメント ＝ AI駆動開発における価値の源泉 / 属人知→AI可読 1 / ©2025 Sun* Inc. | Daiki Miura 

AI時代の思考転換：道具から設計へ 🚫 As-Is：AIを「道具」として"使う"だけ 単発のプロンプトで効率化の限界 個人の効率化に留まる 再現性が低く、チーム全体に広がらない ✅ To-Be：AIを「パートナー」として"設計"する AIをプロセスに統合し、自律的なサイクルを設計 「AIに何をさせるか」を設計する チーム全体の知と生産性を高める基盤となる 単なる「AIユーザー」ではなく、 「AIの可能性を最大限引き出す協働者」を目指す 1 / ©2025 Sun* Inc. | Daiki Miura 

人とAIの役割再定義 👤 人間の役割 目的を定義 制約/評価軸を設計 フィードバックを仕組み化 暗黙知→形式知 🤖 AIの役割 生成・変換 仮説の具体化 改稿・改善の実施 アイデアの発散 - 達成目標の明確化 - ルール/品質基準の設定 - 試行と評価を次に繋げる - 経験の資産化 - 高速な生成 - アイデアを形に - フィードバックからの改善を実施 - 複数案を高速提供 1 / ©2025 Sun* Inc. | Daiki Miura 

AI駆動開発の基本原則 1️⃣ 最小限で十分な情報 質の高いインプット = 質の高いアウトプット ↔️ Garbage In, Garbage Out 必須要素: 目的・制約・参照・評価基準（どれか1つでも欠けると品質に影響） 2️⃣ 高速試行ループ 試行回数 × フィードバック速度 = 質 プロトタイプ→レビュー→改善を高速で回す（一発で当てに行かず細かく刻む） 3️⃣ 知識の資産化 得た知識を構造化知識に変換する 時には「捨てる勇気」も必要 1 / ©2025 Sun* Inc. | Daiki Miura 

コンテキストエンジニアリング 📥 何を渡す？ 仕様・制約 既存コード 用語集・ドメイン知識 ⏰ いつ渡す？ 初期指示時 レビュー時 Just-in-time 🚀 どう渡す？ Web検索 RAG MCP 🎯 コンテキストは有限のリソース トークン数が増えるほどAIの注意力は分散し精度が低下（=Context Rot ※コンテキストの腐敗） → 有益でありながら引き締められた状態を保つことが重要 （=informative, yet tight） → 情報（特にドキュメント）の価値転換 1 / ©2025 Sun* Inc. | Daiki Miura 

ドキュメントの価値転換 🎯 コアメッセージ 「書く」を「資産」に変える AIが読む前提でドキュメントを作成することで、書く行為がそのまま将来の生産性向上への投資になる 🕰️ これまで（人間が読む前提） 📖 物語的・散文的 👥 会議で共有・消費 📝 一度書いたら終わり 🚀 これから（AIも読む前提） 🏗️ 構造化（Markdown / XML） 👥 暗黙知 → 形式知 ♻️ 継続的なメンテナンス・再価値化 1 / ©2025 Sun* Inc. | Daiki Miura 

ドキュメント資産化の実例: Before 😰 当時の課題 🔍 属人化したナレッジ 📚 分散した情報 ⏰ 厳しいリソース制約 📝 実施したこと 📥 ナレッジの収集・追加 • プロジェクト概要 / システム構成 • ビジネスロジック • 不具合調査レポート • 追加開発時の依頼背景・対応手順 → 人力で追加・整理 + Claude Codeでリバースエンジニアリング 🗂️ 集約・構造化 • Google Documentsで一元管理 • リポジトリのdocsフォルダに集約 開発メンバーの頭の中にしかない情報 / 情報格差 Googleスプレッドシートやドキュメント、過去チャット （ほぼ)ワンマン・月数時間という運用体制 1 / ©2025 Sun* Inc. | Daiki Miura 

ドキュメント資産化の実例: After ✅ 活用シーン 👨‍💻 オンボーディング 🔍 調査・開発 🗺️ システム理解 🎯 得られた価値 🗂️ 属人知の解体 ⏱️ 運用負荷削減 🚀 将来への投資 💡 単なる運用改善ではなく、暗黙知をAI可読な資産に変えることで、チーム全体の生産性基盤を構築 新規メンバーの即戦力化 不具合調査や追加開発時の参照 データフロー・遷移図で全体俯瞰 暗黙知 → AI可読な構造化資産 対応力の強化 新メンバー参加時も即戦力化可能 1 / ©2025 Sun* Inc. | Daiki Miura 

コンテキスト・試行・資産化の反復ループ 最小限で十分な情報 アウトプット 改善指示 価値ある知見 次のコンテキストへ再利用 1. コンテキスト設計 目的・制約・評価軸を定義 2. AI による生成 コード、ドキュメント、テスト等 3. 評価・フィードバック セルフレビューと人間による判断 4. 知識の資産化 成功/ 失敗パターンを構造化し蓄積 1️⃣ コンテキスト設計 目的・制約・参照・評価基準を明確に定義 し、AIへ最小限で十分なインプットを準備 2️⃣ AIによる生成 設計されたコンテキストをもとに、コード やドキュメント、テスト等を高速生成 3️⃣ 評価・フィードバック 人間が価値判断を下し、改善指示でループ を回すか、知見を次のステップへ 4️⃣ 知識の資産化 成功/失敗パターンを構造化し、次のコンテ キスト設計で再利用可能な資産に 1 / ©2025 Sun* Inc. | Daiki Miura 

まとめ 💡 明日から始める第一歩 チームのREADMEやドキュメントを整備し、 「コンテキストは有限のリソース」を意識した最小限で十分な情報設計を ⚙️ コンテキスト 設計思考 🔄 高速な 試行ループ思考 🤖 AI可読性を前提に 資産化思考 1 / ©2025 Sun* Inc. | Daiki Miura 

ご清聴ありがとうございました 2025.10 | Thank you for your attention 1 / ©2025 Sun* Inc. | Daiki Miura