生成AIレベル4開発基盤の設計思想

サービスのリニューアルプロジェクト『755 reborn』における生成AI開発基盤構築やPoCの実体験をベースに、レベル4実現に向けた開発基盤構築の全貌を紹介します。各フェーズのPoCで直面した「品質が安定しない」「結局効率化になっていない」といった生々しい課題と、その根本原因をどう特定し、解決へと導いたのか。 試行錯誤の末に見えてきた、自分たちが考える効率と品質を両立できるAI活用の最適解を共有します

Transcript

1. 梶村 律太 Intech Next開発室 755 Reborn プロジェクト バックエンド / AI領域テックリード 755 Reborn Project ⽣成AIレベル4を実現するため の 『開発基盤』の設計思想 755 Reborn GENERATIVE AI LEVEL 4 CHALLENGE 2026.02.24
2. Introduction ⾃⼰紹介 755 Reborn Project 梶村 律太 Rita Kajimura Role Tech Lead Project 755 Reborn Background 2022年新卒⼊社。ABEMAでのバックエンド開発を経て、 現在はIntech Next開発室へレンタル移籍。 Current Role 755 Reborn プロジェクト バックエンド / AI領域 テックリード 横軸組織 技術政策管轄のAI番付推進チーム Mission プロダクト開発プロセスにおける品質の最⼤化と効率化を両⽴する開発基盤の 構築 GENERATIVE AI LEVEL 4 CHALLENGE 2
3. Introduction 755 Reborn プロジェクトの概要 755 Reborn Project REBORN Project Objective 1: Modernization 負債化してしまった既存サービス「755」をモダンスタックでリ ニューアルし、サービス運⽤の持続性を確保する。 Objective 2: AI-Native Workflow AIによる「半⾃動‧全⾃動」開発を前提とした開発フローを構築 し、エンジニアの開発効率を極限まで⾼める。 GENERATIVE AI LEVEL 4 CHALLENGE 3
4. Introduction ⽣成AI活⽤レベル 755 Reborn Project GENERATIVE AI LEVEL 4 CHALLENGE 4
5. Introduction ⽬標はレベル4を実現すること 755 Reborn Project 要件定義から本番デプロイまで、開発プロセス全体を⾃律的に完結させる L1 Code-level Completion コード補完（Copilot等） L2 Task-level Code Generation タスク単位のコード⽣成‧チャットベースの⽀援 L3 Project-level Generation プロジェクトレベルの⾃動化‧複数ステップの実⾏ L5 AI Development Teams AI開発チームによる完全⾃律的な組織運営 L4 PRD to Production / AI Software Engineer 要件策定から本番環境への展開まで、開発プロセスを完全に⾃動化 TARGET GENERATIVE AI LEVEL 4 CHALLENGE 5
6. Introduction レベル4における⼈間とAIの役割分担 755 Reborn Project Main Player AI (⾃律的な開発者) タスクの⾃律遂⾏: 分解から実装までを主導権を持って⾏う ⾃⼰検証ループ: ⼈間のレビュー前にテスト‧Lint‧ガイドラインで品質を⾼める プロジェクト管理: 進捗管理やアラート上げ（報連相）もAIが⾏う Supervisor ⼈間 (監督者) Human-in-the-loop: クリティカルな意思決定と最終承認のみに注⼒ ⾼レイヤーの判断: AIの迷いに対する指針提⽰や仕様の曖昧さの解消 2次レビュー: AIが⾃⼰修正しきった後の最終品質チェック AI Autonomous Cycle SELF-CORRECTION LOOP 修正 タスク管理 報連相 タスク分解 1 成果物作成 設計書‧コード 2 1次レビュー (⾃動検証) Test Lint Guide 3 Pull Request 作成 4 GENERATIVE AI LEVEL 4 CHALLENGE 6
7. Introduction PoCの旅路 755 Reborn Project 直感的指⽰から⾃律的な開発基盤へ。 5つのフェーズを経て進化し続けた技術的アプローチの変遷。 Phase 1 Vibe Coding Phase 2 Spec & Skills Phase 3 Context Engineering Phase 4 Workflow Orchestration Phase 5 Workflow Builder GENERATIVE AI LEVEL 4 CHALLENGE 7
8. Solve the Problem Phase 1: Vibe Coding の実施 755 Reborn Project 初期の成果と直感的な体験 Impact 導⼊初期から即座に効果を発揮 定型的なボイラープレートやユーティリティ関数の⽣成において、「魔 法のように」コードが出⼒される体験。 Speed 体感速度の向上 ⼩粒なタスクであれば、⼈間が考えるよりも速く実装案が提⽰され、開 発リズムが加速する感覚を得られる。 Learning ⼿軽さと未整備な運⽤ 導⼊ハードルは低いが、ルールがないため「個⼈の暗黙知」に依存して いる状態。 AI Coding Assistant ユーザー認証機能を実装したいんだけど、いい感じにお願いできる？ User • 10:23 AM 承知しました。JWTを使用した一般的なログイン機能を実装します。以下 のコードを確認してください。 const login = async (user) => { // ユーザー検証ロジック const token = jwt.sign({ id: user.id }); return { status: 200, token }; } AI • 10:23 AM あ、やっぱFirebase Auth使って書き直して！あとエラーハンドリングも 適当に追加して。 User • 10:25 AM Send a message... GENERATIVE AI LEVEL 4 CHALLENGE 8
9. Phase 1: Problem Vibe Coding の課題 Pain Points Unstructured 品質の不安定性 ⼿順が属⼈化しており、出⼒品質が個⼈のプロンプト⼒やその時の「運」に左右される。再 現性がない。 メンテナンス性の⽋如 プロンプトが個⼈のチャットログに埋もれ、チームでの再利⽤や継続的な改善（資産化） が不可能。 認知負荷の増⼤ 情報の抽出や注⼊を⼈間が⼿動で⾏う必要があり、指⽰出し⾃体が新たな仕事としてエン ジニアを疲弊させる。 スケーラビリティの⽋如 ⼈間との「ターン制」による直列処理がボトルネックとなり、⾃動化や並列化による速度向 上が困難。 Input: Vague Output: Random ⾮構造的な対話の限界 「運」と「個⼈の技量」に依存する状態 Engineer "いい感じに認証機能作って " 品質 Low 品質 High 動作 不明 GENERATIVE AI LEVEL 4 CHALLENGE 9
10. Solve the Problem 解決策: Spec駆動開発 と 明⽰的なSkills Phase 2 755 Reborn Project Vibe Codingからの脱却 「なんとなく」の指⽰をやめ、開発プロセスを資産化する ⾃由⼊⼒（Vibe）から定型化（Asset）へ 毎回考える「使い捨てのプロンプト」ではなく、チームで共 有‧改善できる「資産」として管理する。 成果物テンプレート化でブレ低減 ゴールとなる成果物の構造（Spec）を事前に定義し、AIの出 ⼒フォーマットを強制することで品質を安定させる。 スキルをコマンド化し再現性確保 特定のタスクをこなすための最適なプロンプトを「Skill」と してパッケージ化し、誰でも100%同じ結果を出せるように する。 Spec WHAT to build 成果物の定義 テンプレート Skills HOW to build ⽣成⼿順 コマンド化 Standardized Artifact 定型化された⾼品質な成果物 Reproducible High Quality GENERATIVE AI LEVEL 4 CHALLENGE 10
11. Phase 2 Spec駆動開発 と 明⽰的なSkills 755 Reborn Project ノウハウを「型」と「技」に分離して資産化 Spec駆動開発とは AIに⽣成させるゴール（仕様書やコードなど）の構造とテン プレートを明確に定義し、それを⼊⼒として開発を進める⼿ 法。出⼒の構造的ブレを最⼩化する。 明⽰的なSkills（旧カスタムスラッシュコマンド） 特定のSpecを作るための「最適なプロンプト」を のようなコマンドとしてパッケージ化。 誰でもトップエンジ ニアの指⽰出しを再現可能にする。 Key Benefit 属⼈性を排除し、AIへの指⽰を個⼈の記憶から「組織の資 産」へ転換する。 /plan-prd Spec 成果物の定義‧構造 schema.json Skills 最適な⼿順‧プロンプト /plan-prd High Quality Artifacts 再現性のある⾼品質な成果物 設計書 コード テスト GENERATIVE AI LEVEL 4 CHALLENGE 11
12. Phase 2: Solve the Problem Spec駆動開発 と 明⽰的なSkills の効果 Impact Quality & Speed 開発プロセスの改善指標 成功率 再現性 Quality 100% Consistency 品質の安定化 個⼈のスキルや「運」に依存する要素が排除され、が担保されるようになりま した。誰が実⾏しても同じ⾼品質な成果物が得られます。 Maintainability メンテナンス性の向上 プロンプトがチームのとなり、コードと同様にバージョン管理やテスト、継続的 な改善活動が可能になりました。 Scalability ⾃動化と並列化の実現 ⼿順が決定論的になったことで、これまで不可能だったや並列処理への道が開か れ、開発速度のスケーリングが可能になりました。 100%の再現性 共通資産（SSOT） 定型業務の⾃動実⾏ GENERATIVE AI LEVEL 4 CHALLENGE 12
13. Phase 2 コンテキスト管理の壁 755 Reborn Project プロンプト資産化だけでは越えられない壁 Context Rot 忘却 トークン過多により、初期に与えた重要な前提条件（仕様や制約）がコンテキストウィンド ウから押し出され、AIに無視される現象。 Context Confusion 混乱 無関係な情報が増えS/N⽐（信号対雑⾳⽐）が低下することで、AIが情報の優先順位を判断で きなくなり、出⼒がブレたりハルシネーションが発⽣する現象。 Context Poisoning 汚染 古い仕様書や誤ったコード⽚などの「嘘の情報」が混⼊し、AIがそれを真実として扱うこと で、⼀貫して「間違った」成果物を⽣成し続ける最も危険な現象。 Context Rot Information Fade-out Context Confusion Low S/N Ratio Context Poisoning Fatal Contamination GENERATIVE AI LEVEL 4 CHALLENGE 13
14. Phase 3: Context Engineering 解決策: コンテキストエンジニアリングの導⼊ Solution 755 Reborn Project コンテキストエンジニアリングの役割 プロンプトの「型（Spec/Skills）」だけでは不⼗分。 AIに渡す「情報の質と量」を設計‧制御する仕組みが必要。 Spec (定義) 何を作るか。成果物の構造とゴールを明確に定義。 Skills (⼿順) どう作るか。熟練者のノウハウをプロンプトとして資産化。 3つの要素が揃って初めて、AIは本来の⼒を発揮する Spec 定義‧構造 Skills ⼿順‧⼿法 Context 情報‧前提 NEW Context (情報注⼊) 必要な情報を動的に収集‧選別し、ノイズを排除して注⼊する。 Stable Output GENERATIVE AI LEVEL 4 CHALLENGE 14
15. Phase 3 コンテキストエンジニアリングの解説 755 Reborn Project Definition コンテキストエンジニアリングとは 膨⼤でノイズの多い情報をそのまま渡すのではなく、Skills や成果物の設計段階から⼊⼒情報をコントロールする⼿ 法。 Principle 最⼩化の原則 何でもコンテキストに⼊れるのではなく、必要最低限の情 報に絞り込む。 これがアウトプット品質の最⼤の管理パラメータとなる。 Impact 品質と安定性の向上 AIの認知負荷を下げることで、推論能⼒をコアタスクに集 中させ、ハルシネーションを抑制する。 NG: 過剰‧ノイズ OK: 絞り込み Input (混乱) Output (ブレ‧誤り) Input (最⼩限) Context Filter Output (⾼品質) 1 GENERATIVE AI LEVEL 4 CHALLENGE 15
16. Phase 3 コンテキストエンジニアリングのベストプラクティス 755 Reborn Project 詳細は社内テックブログにて公開中 設計の7つの原則を含む、詳細な実践知⾒はこちら Article URL https://developers.cyberagent.co.jp/blog/archives/60229/ Full Article developers.cyberagent.co.jp/blog/archives/60229/ GENERATIVE AI LEVEL 4 CHALLENGE 16
17. Phase 3 コンテキストエンジニアリングの課題 755 Reborn Project Fragmented Process プロセスの断⽚化 品質確保のためにステップを細分化した結果、⼈間が順次コマンドを実⾏しなければなら ない構造になり、⼿作業の負担が増⼤した。 Increased Latency 待機時間の増⼤ 各コマンドの実⾏中、⼈間はAIの応答を待つだけ。この「待機 × ステップ数」がリードタ イムの⼤半を占める。 No State Management ステータス管理の⽋如 どのコマンドまで完了したか追跡する仕組みがなく、途中で⽌まった場合の再開 （Resume）が困難になった。 Cognitive Load 認知負荷の増⼤ 実⾏状況の把握‧次のコマンドの判断‧エラー対応を⼈間が担うことで、コマンド実⾏⾃ 体が新たな仕事になった。 Time Flow 直列実⾏のボトルネック Human コマンド実⾏ (Step 1) Waiting AI... ⽣成待ち時間 (数分) Human 確認 & 次のコマンド (Step 2) Waiting AI... ⽣成待ち時間 (数分) Human エラー対応 / 再実⾏... GENERATIVE AI LEVEL 4 CHALLENGE 17
18. Phase 4: Solve the Problem 解決策: ワークフローオーケストレーションの導⼊ Phase 4 Automation コマンドの⼿動実⾏から、⾃動実⾏ハーネスへの移⾏ Definition 依存関係の定義 各Skillを「タスク」として定義し、実⾏順序と依存関係をコードで記述 する。 Execution ⾃動実⾏ ハーネスが依存関係に従い、順次‧並列でSkillsを実⾏する。⼈間のコマ ンド操作‧待機‧判断が不要になる。 Management ステータス管理 各タスクの実⾏状況‧成功/失敗をハーネスが追跡し、失敗時は⾃動リト ライまたはエラー通知を⾏う。 Orchestration Harness Status Monitoring Auto Retry Start Skill A Skill B Skill C Review GENERATIVE AI LEVEL 4 CHALLENGE 18
19. Phase 4 ワークフローオーケストレーションの解説 755 Reborn Project 依存関係の定義 各Skillを「タスク」として定義し、実⾏順序と依存関係をコードで記述。複雑な 条件分岐や並列処理もプログラムとして表現可能。 ⾃動実⾏‧制御 ハーネスが依存関係グラフ（DAG）に従い、順次‧並列でSkillsを⾃動実⾏。⼈間 によるコマンド操作‧待機時間‧次ステップの判断が⼀切不要に。 ステータス管理 各タスクの実⾏状況‧成功/失敗をハーネスが追跡。失敗時の⾃動リトライやエ ラー通知機能により、運⽤負荷を⼤幅に軽減。 Feature Development Workflow Running 00:03:42 Parallel Execution Enabled Orchestrator: Prefect TASK-01 Spec Generation Duration: 45s TASK-02 Test Plan Duration: 30s TASK-03 DB Schema Duration: 25s TASK-04 Impl. Handler Running... TASK-05 Impl. Repository Waiting TASK-06 Create PR Waiting GENERATIVE AI LEVEL 4 CHALLENGE 19
20. Phase 4 ワークフローオーケストレーションの効果 755 Reborn Project Manual Execution 従来の直列的な⼿動実⾏フロー 直列処理による待機時間の累積 コマンド実⾏のたびにAIの応答を数分待つ必要がある 操作オーバーヘッドと認知負荷 ステータス確認、次⼿判断、エラー対応が全て⼿動 プロセス断⽚化のリスク ⼿順のスキップやパラメータミスが発⽣しやすい Auto Orchestration 並列‧連続のノンストップ実⾏ 並列化によるリードタイム短縮 依存関係のないタスクを同時実⾏し、待ち時間をゼロに 品質プロセスの強制 テスト‧Lint‧レビューをパイプラインに組み込み品質担保 周辺ツール連携による拡張性 GitHub/Slack等と連動し、ステータス管理を外部委譲 ⼈間がボトルネック Task A: Spec Generation Task B Task C Task D: Final Integration 速度と品質を最⼤化 CMD Wait CMD Wait CMD GENERATIVE AI LEVEL 4 CHALLENGE 20
21. Phase 4: Workflow Orchestration なぜ Prefect なのか 755 Reborn Project 実行状況の可視化と制御 選定の決め⼿となった3つの要件 Code as Definition ワークフロー定義のコード管理 Pythonコードとして定義できるため拡張性が無限。YAMLベースとは異なり、「AIにワー クフロー⾃体の実装を依頼」することが容易に可能。 Dynamic Generation 動的なタスク⽣成 LLMの出⼒や実⾏時状況に応じてタスクを動的に変更可能。⾮決定的なAI開発におい て、事前に全てを定義できないケースに対応できる。 Security 認証認可の堅牢性 APIキーやロールベースの権限管理(RBAC)が標準装備。「誰でも実⾏できる状態」を防⽌ し、本番運⽤に耐えうるセキュリティを確保。 Prefect Cloud - Flow Runs Completed Spec-to-PR Flow 24s duration > Flow run 'intelligent-dolphin' started > Task 'generate_spec' finished successfully > Task 'run_tests' finished successfully > Task 'create_pr' finished successfully GENERATIVE AI LEVEL 4 CHALLENGE 21
22. Phase 4 ワークフローオーケストレーションの課題 755 Reborn Project Phase 5: Workflow Builderへ 新たな構造的課題 Problem 01 属⼈化とスケール不全 ワークフローやSkillsの品質を担保するための設計知識（依存関係の定義 など）が⾼度化し、特定のテックリードに依存してしまう。結果、組織全 体への⽔平展開が困難になる。 Problem 02 開発プロセスの停滞 1つ1つのタスクに対する設計コストが⾼いため、ワークフローの整備ス ピードが開発需要に追いつかない。「⾃動化のための準備」⾃体が新たな ボトルネックとなり、本末転倒な状況を招く。 属⼈化 特定メンバーしか設計できない スケール不全 組織への展開困難 整備の遅れ Workflow実装が追いつかない 開発停滞 プロセスがボトルネック化 設計難易度‧コストが⾼い Skills定義 / 依存関係の設計 GENERATIVE AI LEVEL 4 CHALLENGE 22
23. Phase 5 ワークフローを構築するワークフロー 755 Reborn Project 現在の到達点 Objective 設計の属⼈化‧コストの解消 ワークフロー設計やカスタムコマンドの作成には⾼度な知識が必要だっ た。この「設計プロセス」⾃体が新たなボトルネックとなるのを防ぐ。 Approach 設計⾏為をAIに委譲する 「ワークフローを作るためのワークフロー」を構築。最終成果物から逆 算して、必要なSkillsと依存関係をAIが⾃律的に設計‧検証‧修正する仕 組みを導⼊。 Result メタ階層による完全⾃律化 ⼈間は「何が欲しいか（Golden Data）」を定義するだけ。あとは Builderが実⾏⽤のWorkflow（Dev Workflow）を⾃動⽣成し、実⾏可能 な状態にする。 Level 2: Builder Workflow Builder 設計の⾃動化‧逆算 Golden Data Spec Design Verification Generate & Optimize Level 1: Execution Dev Workflow 成果物の⽣成‧検証 Task A Task B PR Created GENERATIVE AI LEVEL 4 CHALLENGE 23
24. Phase 5 ワークフロー構築ワークフローの解説 755 Reborn Project Methodology 逆算アプローチ 最終成果物からを作成し、そこから必要なSkillsとInput成果物を逆算し て設計します。実⾏結果を正解データと⽐較‧修正しながら、開発プロ セスの起点まで推し進めます。 Governance ワークフローとして強制 設計‧実⾏‧⽐較‧修正のサイクル⾃体をワークフロー化。コンテキス トエンジニアリング等ので担保し、属⼈性を排除して品質を組織的に保 証します。 Golden Data ベストプラクティスへの準拠を⾃動レビュー 逆算設計 Verification Cycle 1 Skills実⾏‧成果物⽣成 2 Golden Dataと⽐較検証 3 プロンプト/成果物を修正 このサイクルを開発の起点まで遡る Goal Definition Golden Data (正解データ) Reverse Design Skills & Input 設計 GENERATIVE AI LEVEL 4 CHALLENGE 24
25. Phase 5 ワークフロー構築ワークフローの効果 755 Reborn Project Effect 01 属⼈性の解消 設計の判断基準が「ワークフロー」そのものに組み込まれ るため、特定のトップエンジニアへの依存がなくなりま す。誰でも同じ品質でワークフローを構築できる状態が実 現しました。 Effect 02 設計コストの削減 Golden Dataからの「逆算アプローチ」が標準化されまし た。新しい開発タスクが発⽣するたびにゼロから⾏ってい た設計⼯数が、AIによる⾃動⽣成で⼤幅に削減されます。 Effect 03 ⾼速な改善サイクル ワークフローの修正‧改善プロセスも⾃動化されていま す。組織として継続的に品質を向上させ続ける「⾃律的な 進化」が可能になりました。 BEFORE Phase 4: ワークフロー導⼊の課題 属⼈化 設計⾼コスト 開発停滞 AFTER Phase 5: 構築ワークフローの効果 誰でも構築 ⾃動設計 ⾼速改善 GENERATIVE AI LEVEL 4 CHALLENGE 25
26. Conclusion Lv4を実現できる開発基盤構築の全貌 755 Reborn Project 5層構造による⾃律開発 SpecからBuilderまで、5つのレイヤーが積み重なることで、初めて⼈間が介 在しない「⾃律的な開発」が成⽴します。単⼀のレイヤーだけでは不⼗分で あり、すべての層が必要です。 独⽴性と相互補完 各レイヤーは独⽴して機能しますが、下層が上層を⽀え、上層が下層を制御 する形で相互に補完し合います。コンテキスト（L3）がなければワークフ ロー（L4）は機能せず、Skills（L2）がなければBuilder（L5）は作動しませ ん。 L4: 組織としての⾃律実⾏ 個⼈の「プロンプト芸」から脱却し、組織として開発プロセス全体をコード 化‧資産化することで、Level 4（PRD to Production）の実現が可能になり ます。 ARCHITECTURE STACK Workflow Builder ワークフロー設計の⾃動化 逆算アプローチ / ⾃動⽣成 Workflow Orchestration Skillsの⾃動実⾏‧ステータス管理 Prefect / DAG実⾏ Context Engineering AIへの⼊⼒情報の設計‧制御 S/N⽐向上 / 汚染防⽌ Skills どう作るかの⼿順（Asset） カスタムスラッシュコマンド Spec 何を作るかの定義 構造化された成果物テンプレート
27. Conclusion メリット‧効果 755 Reborn Project Phase 2: Spec & Skills 属⼈性が排除され、誰が実⾏しても100%の再現性が担保される状態へ。 プロンプトが資産化された。 Phase 3: Context Engineering ⼊⼒情報の制御によりアウトプット品質を担保。AIの失敗原因を論理的に 特定‧修正可能になった。 Phase 4: Workflow Orchestration ⼈間の待機時間をゼロにしリードタイムを短縮。品質チェックを強制化 し、並列処理によるスループット向上を実現。 Phase 5: Workflow Builder 設計コストを⼤幅に削減し、属⼈性を完全に解消。組織として⾼速に改善 サイクルを回せる体制が整った。 Phase Key Impact P2 Spec 品質安定化‧属⼈性排除 再現性100%の実現 P3 Context 品質担保‧論理的デバッグ アウトプット品質の制御 P4 Workflow リードタイム短縮‧⾃動化 品質強制と並列化 P5 Builder 設計コスト削減‧⾼速改善 組織的スケーラビリティ GENERATIVE AI LEVEL 4 CHALLENGE 27
28. Conclusion デメリット‧課題 Reality Check 導⼊のハードル 導⼊条件は厳しい 魔法のような解決策ではなく、 ⾼い導⼊コストと 覚悟が求められます。 High Cost 導⼊コストの⾼さ 通常の開発プロジェクトとの並⾏導⼊は⾮現実的です。 が 絶対的な前提条件となります。 System Scale 既存システムの規模 刷新対象のシステムが⼤きいほど、ワークフロー化すべき プロセスの範囲が広がり、導⼊難易度が指数関数的に上がります。 → スコープを区切った段階的導⼊が必須 Organizational Complexity 組織の規模と複雑性 組織が⼤きいほど成果物の定義が複雑化し、 依存関係の設計コストが増⼤します。 スモールスタートが困難になり、合意形成に時間がかかります。 基盤構築に専念できるリソースと期間の確保 GENERATIVE AI LEVEL 4 CHALLENGE 28
29. Conclusion まとめ 755 Reborn Project 1 2 3 スモールスタートと 横展開 まず特定の開発タスク1つに絞ってスコープ を限定して導⼊し、実績を作ってから横展開 する。最初から全⼯程のワークフロー化を⽬ 指す必要はない。 コンテキスト基準の 整備から始める ワークフロー化が難しい場合でも、コンテキ ストの整理⽅針やその基準をチーム内で定め ることはすぐにできる。これだけでもアウト プット品質は向上する。 「個⼈の技」から 「組織の基盤」へ プロンプトの⼯夫という属⼈的な「個⼈の 技」に依存するのをやめ、チーム誰でも同じ 品質で再現できる「組織の基盤」としての仕 組みに転換する。 NEXT ACTION: まずは「1つのタスク」の構造化から始めましょう 29