ハーネスエンジニアリング×AI適応開発

AI駆動開発で本当にボトルネックになるのは、コードを書くことではなく、人間の理解・判断・レビューです。
本スライドでは、OpenAIが2026年2月11日に公開した記事「Harness engineering」の要点を踏まえつつ、当社（Shunkan AI）での実践をもとに、AI活用の効果を最大化するための「仕組み・プロセス・体制」の再設計について解説します。

7万行規模のSaaSを2人月で開発した経験から見えてきたのは、AIを導入するだけでは生産性は伸びず、AIが力を発揮しやすい環境整備が不可欠だということでした。そこで本スライドでは、理解負債やレビュー負荷の問題をどう捉え、どのようにハーネスを整備し、責任を果たせる状態を維持しながらAI活用を拡張していくかを具体例とともに紹介します。

AI時代の開発組織に求められるのは、単なるツール導入ではなく、責任構造の再設計です。
「AIに任せること」「自動化すること」「人が担うこと」をどう整理し、再現性のある高効率な開発体制をどう作るのか。現場で実践可能な考え方とアプローチをご紹介します。

※本スライドは、2026年03月30日に開催したオンライン勉強会 BPStudy#223 の発表資料です。

Transcript

1. BPStudy#223 ハーネスエンジニアリング × AI適応開発 AI駆動開発の理解負債‧レビュー負荷を「仕組み」で解く 神⾕ 亮平 ｜ Shunkan AI株式会社 取締役CTO @k38ryohei
2. 01 ⾃⼰紹介 02 これまでの取り組みと、ハーネスエンジニアリング 03 OpenAI「Harness engineering」の要点 04 組織の課題と解決策（AI活⽤効果を⾼める前提条件と、その整理と活⽤について） 本⽇の流れ 2 2026-03-30 ©Ryohei Kamiya 05 まとめ 06 質疑応答
3. 神⾕ 亮平 (Kamiya Ryohei) Shunkan AI 株式会社 取締役 CTO 約20年前からAI技術を活⽤してきたエンジニア。製造業、ビッグデータ、IoT、不動産テック、 Web業界で開発に従事。2023年秋に、新規事業企画のコミュニケーション課題を解決するAI エージェントを独⾃に開発。翌年Shunkan AI を共同創業し、「システムエージェント」とし て製品化。2024年末〜2025年2⽉にかけて、7万⾏規模のSaaSを2⼈⽉、従来⽐約50倍の開発 効率で開発。その実践知を基に「AI適応開発」を提唱し推進中。 • システム開発の実務⽂脈において、AI活⽤による組織変⾰を⽀援。 • 「⽣成AI×システム開発 実践講座（インプレスアカデミー）」登壇講師。 • 専⾨メディア（Business + IT / Think IT）への掲載実績あり。 3 ⾃⼰紹介 2026-03-30 ©Ryohei Kamiya
4. ご質問‧ご感想のシェアのお願い ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！ 1 ご質問‧ご感想は X でお知らせください 発表中に気になったこと、感想があれば、X で #bpstudy をつけてポストしてください。 2 質疑応答で紹介‧回答いたします 投稿の中から、発表後の質疑応答の時間にピックアップして紹介‧回答させていただきます。 3 取り上げきれなかったご質問は、Xでフォローいただければ後⽇回答いたします 本⽇は時間に限りがあるため、すべてを取り上げきれない場合があります。 回答を希望される⽅は @k38ryohei のフォローをお願いします。後⽇リプ欄で回答いたします。 4 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
5. これまでの取り組みと、 ハーネスエンジニアリング 56倍効率のSaaS開発と、その先の「再現性」への挑戦 2026-03-30 ©Ryohei Kamiya 5
6. そもそも、ハーネスとは？ → ハーネスとは、 「体や物を安全に固定したり、⼒を効率よく伝えたりするための、ベルト状の装具」のこと 6 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
7. つまり、ハーネスエンジニアリングとは ハーネスエンジニアリングとは、 「AIを安全に制御し、能⼒を効率よく発揮させるための環境整備活動」 のこと 7 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
8. 56倍効率のSaaS開発経験（2024年12⽉〜2025年02⽉） 従来の開発 AI適応開発 ポイント 当社独⾃開発のAIエージェント「システムエージェント」で要件定義書/モックを⾃動⽣成し、 AIエディタ（Cursor）を使って実装。開発の全⾏程をエンジニア1⼈が担当。 コードステップ数が 約 7 万⾏のシステムを開発。 IPA「ソフトウェア開発分析データ集2022」の⽣産性指 標の中央値に基づく⼯数は約113⼈⽉。 AIエージェントを活⽤し、 1名×2ヶ⽉(2⼈⽉)で完了しました。 単純計算で 56倍の開発効率でした。 8 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
9. 56倍効率のSaaS開発経験からの気づき AIを活⽤することで、次が可能になりました。 01 開発プロセスの⾃動化 効果 「調査検討‧情報整理などの作 業時間」の削減 02 要求‧要件の早期可視化 効果 「コミュニケーションの不備」 の回避‧低減 03 少数精鋭での開発体制 効果 「確認‧調整‧待機などの⾮⽣ 産時間」の削減 効率が上がったのは、単純に「AIを使ったから」だけではない → 「AIの活⽤効果が出やすい仕組み‧プロセス‧体制」が揃っていた 9 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
10. 製品ローンチ時の発表会での反応 製品発表会の場で、経験と気づきを共有。そして、その時にいただいた反応： 「あなただからできたのでは？」 その反応に対して感じたこと： 「真似るだけで同様のことができるのに、もったいない！」 10 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
11. 「再現性」への挑戦の始まり しかし、⾔われてみれば、確かに属⼈的な要素もあることに気づいた 誰でも簡単に真似できるようにするには、もっと仕組み化‧整理が必要かも… 「誰でも‧どんな組織でも安定的に10倍以上の開発効率」 を再現できる仕組みづくりの挑戦が始まった 11 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
12. 再現性を実現するためのアプローチ 課題：既存のプロセス‧体制やテックスタックは会社ごとに異なる → その差異によらず再現性を実現するには？ 具体的な取り組み 1 開発プロセス‧体制の整理 • 56倍効率の開発プロセスを「企画‧要件定義」「プロトタイプ開発」 「本番開発」の3フェーズに分解 • 各フェーズの「責任」「実施内容」「体制」を整理 2 仕組み（開発キット）の整備 • AIエージェントが安全に動作する隔離開発環境（DevContainer）を構築 • 企画‧要件定義からプロトタイプ開発へスムーズに接続する仕組みを整備 • 決定論的ツールを活⽤し、AIに頼りきらないアーキテクチャを設計 ▼ 実践知をフレームワークとして昇華 フレームワーク AI適応開発 • 実践で得た情報整理の考え⽅‧⽅法‧判断基準を標準化し、組織やツールの違いによらない共通基盤として体系化 • ISOやリスクマネジメントの⼿法をベースに設計 • 組織学習サイクルを組み込み、AIの進化‧普及に合わせて継続的に改善するアプローチ • 上記「具体的な取り組み」①②の成果はリファレンス実装として位置づけ ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！ 12 2026-03-30 ©Ryohei Kamiya
13. 前スライドの「②仕組み（開発キット）の整備」は、 2026/02/11にOpenAIが公開した記事をきっかけに最近話題になっている 「ハーネスエンジニアリング」と同種の取り組みでした この後、1年以上の実践からの経験をもとに OpenAIの記事の要点を解説します 2026-03-30 ©Ryohei Kamiya まさに「ハーネスエンジニアリング」と同じことに取り組んできた ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！ 13
14. さらっと読むと... ツールや技術の話に⾒える しかし本質は... ある「組織的な判断」が前提 この「⾒えにくい前提」に気づけるかどうかで 現場でのAI活⽤の進め⽅も、その成果も ⼤きく変わってくる 2026-03-30 ©Ryohei Kamiya 経験のフィルタ越しに⾒える、記事の背後の「⾒えにくい前提」 ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！ 14
15. 開発⽤のAIツールを導⼊する できるだけAIに任せようとする 期待ほどスピードが上がらず、 ⼀部の⼈に負荷が集中して疲弊する 原因は？ 組織の前提が （仕組み‧プロセス‧体制） 変わっていないから AIがなかった時代の仕組み‧プロセス‧体制のまま AIだけを「後づけ」しても、うまくいかない 2026-03-30 ©Ryohei Kamiya よくある現場の落とし⽳ ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！ 15
16. 「その前提、AIがなかった時代の ものじゃないですか？」 最新エンジン（AI）を積んでも、 道路（仕組み‧プロセス‧体制などの前提）が旧来のままなら、 ポテンシャルはゼロになる。 16 2026-03-30 ©Ryohei Kamiya
17. では、どうしたらよいか？ 解決策の紹介に移る前に、 まずOpenAIの記事を読み解くところから始めましょう 2026-03-30 ©Ryohei Kamiya 17
18. OpenAIの実践から学ぶ、「ハーネスエンジニアリング」の要点を解説します。 OpenAI 2/11 公開記事「 Harness engineering」の要点 https://openai.com/ja-JP/index/harness-engineering/ 18 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
19. OpenAI「⼈間は⼀⾏もコードを書かず開発」 5ヶ⽉ 期間 3⼈ 開始⼈数 約1,500 PR数 約100万⾏ コード規模 ⼿書きコードは⼀切使わない⽅針で開発が進められました。 → 「⼈間は直接コードを書かずに開発」が可能になった ※ 出典：OpenAI「Harness engineering: leveraging Codex in an agent-first world」 19 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
20. AI活⽤で変わったのは「ボトルネック」 AIの能⼒ AIは⼤量のコードを ⾼速に⽣成できる ⼈間の能⼒ ⼈間の理解‧判断‧QAの 速度は急には増えない vs 希少資源は「⼈間の時間と注意⼒」になる ボトルネックは、書くこと‧作成することから⼈間が読むこと‧確かめることへ移る ※ 出典：OpenAI「Harness engineering: leveraging Codex in an agent-first world」 20 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
21. OpenAIの主張「スループットがマージの考え⽅を変える」 01 PRは短期間で閉じる 02 ブロックするマージゲート は最⼩限 03 問題はフォローアップで 直す運⽤を取る → エージェントのスループットが⼈間の注意⼒をはるかに上回るシステムでは、 修正は安価で、待機は⾼コスト ※ 出典：OpenAI「Harness engineering: leveraging Codex in an agent-first world」 21 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
22. つまり、PRのマージが短期間だから（当然）開発が速い 1 PRは短期間で閉じる ブロックするマージゲートは最⼩限に。 問題はフォローアップで対応 → 2 マージの回転が速い 修正は安価、待機は⾼コスト。 ⽌めるより流して直す⽅が効率的 → 3 開発スピードが上がる ⾼スループットのサイクルが、 結果として開発全体の速度を押し上げる PRのマージが速い = 開発サイクルが速い レビュー待ちで⽌まらず、⾼速にマージ→フィードバック→修正を回すことで、 開発全体のスループットが劇的に向上する ※ 出典：OpenAI「Harness engineering: leveraging Codex in an agent-first world」 ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！ 22 2026-03-30 ©Ryohei Kamiya
23. ただし、これは⼀般解ではない 01 低スループット環境では 不適切 02 どの組織でもそのまま 真似できるわけではない 03 条件付きで成⽴している 運⽤判断である → 「OpenAIがそうしている」≠「⾃社でもそうすべき」 （ イコールではない ） ※ 出典：OpenAI「Harness engineering: leveraging Codex in an agent-first world」 23 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
24. なぜOpenAIでは「短期間でマージ」ができるのか？ 01 前提①：ハーネスを作り込んでいる 環境を設計し、意図を明確にし、Codexが信頼 性⾼く働けるフィードバックループを構築 → ハーネスを作り込み、継続的に改善している 02 前提②：「適切な妥協点」という組織的判断 エージェントのスループットが⼈間の注意⼒を はるかに上回るシステムでは、修正は安価で、 待機は⾼コスト → 多くの場合、 「短期間でマージ」は「適切な妥協点」である 24 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
25. エージェントが信頼性⾼く動くための環境設計 01 コンテキストエンジニアリング リポジトリ内に構造化されたナレッジベー スを構築。AGENTS.md を「⽬次」として 約100⾏に抑え、設計⽂書‧アーキテク チャマップ‧実⾏計画‧品質基準への参照 を提供 エージェントが⾒えないものは存在しない。リポジ トリが唯⼀の情報源 02 アーキテクチャ制約 厳格なレイヤード‧アーキテクチャを機械 的に強制。カスタムリンター＋構造テスト で依存⽅向を検証し、違反はマージ前に検 出‧ブロック 制約こそが速度を⽣む。⼀度エンコードすれば全箇 所に即座に適⽤ 03 エントロピー管理 バックグラウンドエージェントが定期的に ドキュメントの陳腐化や制約違反を検出 し、⾃動でクリーンアップPRを作成。⼈間 の介⼊なしに品質を維持 ハーネスへの投資は複利で効く。改善が次の改善を 加速させる エンジニアの仕事は「コードを書くこと」から「環境を設計すること」へ ※ 出典：OpenAI「Harness engineering: leveraging Codex in an agent-first world」 OpenAIのハーネス：3つの柱 25 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
26. 実際にどのような仕組みでエージェントの信頼性を担保しているか ナレッジベースとオブザーバビリティ •AGENTS.md：約100⾏の「⽬次」。設計⽂書‧品質基準‧実 ⾏計画への参照を集約 •構造化docs/：アーキテクチャマップ、設計仕様、品質評価を 機械的に相互参照 •実⾏環境の可視化：Chrome DevTools連携でUI確認、ログ‧ メトリクス‧トレースをタスク単位で分離提供 機械的な制約と強制 •レイヤードアーキテクチャ： Types→Config→Repo→Service→Runtime→UIの⼀⽅向依存 を厳格に強制 •教えるリンター：エラーメッセージに修正⽅法を埋め込み、 違反検出と同時にエージェントを「指導」 •Providers：認証‧テレメトリ‧機能フラグなどの横断関⼼事 は単⼀インターフェースで注⼊ エージェントが苦戦したら、それはシグナル → ⾜りないもの（ツール‧ガードレール‧ドキュメント）を特定し、ハーネスに還元する ※ 出典：OpenAI「Harness engineering: leveraging Codex in an agent-first world」 OpenAIのハーネス：具体的な仕組み 26 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
27. 環境の整備がエージェントの⾃律性を決定づけるが、汎⽤的に流⽤できるものではない 環境整備の重要性 「初期の進捗は予想より遅れましたが、それは Codex に能⼒がなかったからではなく、環境が⼗ 分に定義されていなかったためです。」 → ハーネス（環境‧ツール‧構造）を整えること で、エージェントの⾃律性と開発速度が向上する 汎⽤性の限界 「エージェントの⾃律的な動作は、リポジトリの 特定の構造とツールに⼤きく依存しており、同様 の準備なしに⼀般化できると考えるべきではあり ません。少なくとも、現時点では。」 → 開発対象やテックスタックごとに最適なハーネ スは異なり、汎⽤的に流⽤できるものではない （少なくとも、現時点では） ハーネスは開発対象‧テックスタックごとに設計するもの OpenAIの⾒解：ハーネスの重要性と限界 ※ 出典：OpenAI「Harness engineering: leveraging Codex in an agent-first world」 27 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
28. 公開ライブラリに依存せず、エージェントが直接制御できる形態にすることでレバレッジが向上する 「外部ライブラリ依存排除」の判断基準と実例 「汎⽤的な p-limit スタイルのパッケージを導⼊する代わりに、独⾃の並⾏処理対応マップヘルパーを実装しました。 OpenTelemetry の計装と緊密に統合され、テストカバレッジは100%です。」 → 公開ライブラリの不透明な挙動を回避し、システムのより多くの部分をエージェントが直接検査‧検証‧変更できる 形態にすることでレバレッジが向上する エージェントが検査‧検証‧変更可能な形態 ＝ レバレッジ向上の鍵 不透明な上流依存を排除 → ⾃社ランタイムへの最適化 → テスト‧計装の完全統合 OpenAIの知⾒：「外部ライブラリ依存排除」でレバレッジ向上 ※ 出典：OpenAI「Harness engineering: leveraging Codex in an agent-first world」 28 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
29. ⼈間による⼿作業のコーディングの削減は、新たな種類のエンジニアリング作業をもたらした 「⼈間による⼿作業のコーディングの削減は、システム、スキャフォルディング、そしてレバレッジに焦点を当 てた新たな種類のエンジニアリング作業をもたらした」 従来のエンジニア •コードを書く •コードをレビューする •⼿作業でバグを修正する 新しいエンジニア •環境を設計する •意図を明確に指定する •フィードバックループを構築する 求められる問い •「何の能⼒が⾜りないのか？」 •「エージェントに読みやすく強制可能にす るには？」 規律の所在が変わった：「コードの中」から「スキャフォルディングの中」へ ※ 出典：OpenAI「Harness engineering: leveraging Codex in an agent-first world」 エンジニアの役割の再定義 29 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
30. スキャフォルディング（⾜場づくり）？ 【 例1 】 $ rails generate scaffold … 【 例2 】 $ dotnet ef dbcontext scaffold … 【 例3 】 $ php artisan make: … 30 エンジニアが思い浮かべるであろう具体例 注：なお、「⾜場」の作り⽅はコマンド実⾏による⽣成に限らない （ボイラープレートのコピーもスキャフォルディング） 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
31. OpenAIも「まだ学んでいる」 01 ⻑期的なアーキテクチャの ⼀貫性は未確定 02 ⼈間の判断が最も効果を 発揮する領域もまだ学んでい るところ 03 この先、システムが どう進化するか分からない → これは絶対的な正解ではない → 現時点での、率直な実践知である ※ 出典：OpenAI「Harness engineering: leveraging Codex in an agent-first world」 31 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
32. 記事の「⾒えにくい前提」とは何か？ ここまでの解説を踏まえて、 記事の裏にあるOpenAIの「組織的な判断」を読み解きます 2026-03-30 ©Ryohei Kamiya 32
33. あなたの会社で、OpenAIと同じ判断ができますか？ ? PRを短時間で流せるか？ ? 問題が起きたら後で直せる か？ ? その判断の影響‧結果を、 組織として引き受けられる か？ → OpenAIで成⽴していることが、そのまま⾃社で成⽴するとは限らない 33 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
34. 同じ判断を採⽤しにくいケースは、実際に珍しくない 01 ⼤規模SIサービスでは、 契約‧説明責任‧顧客合意 が重い 02 医療‧⾦融‧インフラ向けで は、許容できる失敗の幅が 狭い 03 ⾃社開発SaaSでも、 障害影響が⼤きい場合は 慎重になる → 「細部を確認せずに短期間でマージ」が採⽤しにくいのは珍しいことではない 34 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
35. しかし、問われる「品質 vs 効率」の両⽴ A 「品質低下のリスクがある から細部まで確認必須」 vs 品質と効率、 両⽴しにくい要請の中で 板挟みになる B 「効率を上げたいから とにかくAI活⽤！」 → 必要なのは、これらの⾼まる要求に組織としてどう応え続けるかを設計すること 35 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
36. 問題は「できない理由」があることではない → 問題は、品質と効率を両⽴する「責任の果たし⽅」が決まっていないこと 36 2026-03-30 ©Ryohei Kamiya 障害リスク、保守性の低下、説明責任の困難さ… これらは単なる慎重論ではなく、 組織が実際に負っている責任を考えれば、 どれももっともな理由である ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
37. では、実際に解くべき課題は何か？ 01 維持すべきこと 求められる責任を果たせる状態を維持する 02 変えるべきこと そのうえで、AI活⽤の範囲を拡げ、深める → 課題は「AIツールの機能‧性能‧使い⽅」ではない → 「責任を果たせる状態のまま、AI活⽤を拡張できるか」である 37 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
38. 責任を果たせる範囲で適切にリスクをコントロールした上での、開発‧利⽤‧情報公開 1 開発⽅針の判断 エージェントのスループットが⼈間 の注意⼒をはるかに上回るシステム では、修正は安価で、待機は⾼コス ト。問題は後から直せばよいと判断 2 利⽤範囲のリスクコントロール いきなり外部に公開せず、「α版」と して社内ユーザーとアルファテス ターに限定。問題発⽣時に備えたリ スクコントロール 3 情報公開による⼼理的な受容の下地づくり 従来と⼤きく異なる⼿法への⼼理的抵抗を⾒ 越して情報を公開。「合理的な妥協である」 という判断を開⽰することで、先端PRとマイ ンド転換に貢献 OpenAIとして責任を果たせる範囲で 適切にリスクをコントロールした上での 開発‧利⽤‧情報公開であった （つまり、責任を果たせる状態のまま、AI活⽤を拡張した） 2026-03-30 ©Ryohei Kamiya OpenAIの「責任の果たし⽅」の組織的な意思決定（③は推察） ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！ 38
39. つまり、OpenAIの記事の「⾒えにくい前提」とは、 「責任の果たし⽅」の組織的な意思決定 ⾃社でAI活⽤を進める際にも、 同様の意思決定が必要 2026-03-30 ©Ryohei Kamiya 39
40. では、⾃社では何を決めなければならないか？ 01 品質の保証範囲 どこまでを仕組みで 保証するか？ 02 ⼈間の関与の線引き どこからを⼈間が 判断‧承認するか？ 03 実⾏可能な環境づくり 責任を果たせる条件を どう整えるか？ この3つの問いに組織として答えること それが「責任構造の再設計」です 40 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
41. 「責任構造の再設計」は、何を⾒直すことなのか？ 01 仕組みの⾒直し •AIが安全かつ効率的に動ける環境 （ハーネス）を作る •⾃動で保証できることを増やす 02 開発プロセスの⾒直し •開発をどの段階に分けるか •各段階でAIと⼈がどう関与するか 03 ⼈間の役割‧組織体制の⾒直し •誰が何に責任を持つのかを 再定義する •責任を果たせる体制に組み替える → 責任構造の再設計とは、仕組み‧プロセス‧体制を⼀体で⾒直すこと 41 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
42. では、⾒直しはどう進めればよいのか？ 理想 トップダウンで⼀度に⾒直せると早い 組織全体を⼀気に変⾰できれば、 最短で効果を出せる 現実 多くの組織ではそれが難しい 現⾏の事業‧業務への 影響が⼤きいから → 理想は⼀気に⾒直すこと → 現実には、そう判断しにくいことが多い 42 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
43. 段階的に進めるにしても、組織の判断は必要 01 個⼈の⼯夫だけでは、 仕組み‧プロセス‧体制は 変えられない 02 段階的でも、 何をどの順で変えるかは 組織の意思決定 03 だから、 判断の拠り所が求められる → ⼀気でも段階的でも、組織的な意思決定は避けられない → では、その判断を何を拠り所に進めるか？ 43 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
44. 判断の拠り所がないと、何が起きるか？ 01 ⽅向性が定まらず、 議論が空転する 02 各⾃がバラバラに動き、 整合性が取れない 03 結局、 現状維持に戻ってしまう → 必要なのは、組織的な意思決定を⽀えるブループリント 44 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
45. ブループリントを作るには、整理の「軸」が必要 01 まず「何を軸に整理するか」を 決める必要がある 02 代表的な軸は 「タスク」と「成果物」の2つ 03 どちらを選ぶかで、 議論の進め⽅が⼤きく変わる → ブループリント作りでは、何を軸に整理するかが重要になる 45 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
46. 整理の軸：「タスクベース」と「成果物ベース」の⽐較 ① タスクベース •「何をやっているか」を軸に整理 •タスクごとに仕組み‧体制を⾒直す ② 成果物ベース •「何を作っているか」を軸に整理 •成果物ごとに仕組み‧体制を⾒直す → どちらも可能。ただし、おすすめは② 成果物ベース 46 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
47. なぜ、成果物を軸とした整理がよいのか？ 01 責任構造の再設計では、 タスク⾃体が変わる 02 タスクを基準にすると、 既存業務の効率化に寄りやすい 03 成果物を基準にすると、 必要な仕組みをゼロベースで 考えやすい → 問うべきは「この成果物を成⽴させるには何が必要か？」 47 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
48. 多くの組織では、「AI前提に⼀気に変更」は難しい 01 現⾏の仕組み‧プロセス‧ 体制が、すでに業務に深く 組み込まれている 02 AI前提の形へ⼀度に変えるの は判断しにくい 03 ブループリントを拠り所に 「移⾏プラン」を⽴てて進 める → 重要なのは、理想形を知ることだけでなく、そこへの移⾏経路を設計すること 48 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
49. 事例紹介：⼈⼿作業‧⽬視確認中⼼の開発業務へのAI導⼊ 01 要件‧設計は Excel で記録‧管理している 02 ⼈⼿で整理し、複数⼈が⽬視で多重レビューしている 03 AIツールは導⼊済みだが、 どこで効くか分からず活かしきれていない → AIツールはある → でも、AIが効く形に情報と業務が整っていない 49 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
50. 事例紹介：移⾏の第⼀歩は「AIが扱える形」に変換すること 1 変換 Excel → テキスト変換 要件‧設計のExcel形式を、 AIが処理しやすい テキスト形式に変換する 2 整備 開発環境の整備 変換後のテキストを 効率的に扱える 開発環境（ハーネス）を整える 3 活⽤ AI活⽤の⼟台づくり AIが読める‧⽐較できる‧ 再利⽤できる状態を作り、 本格的なAI活⽤へつなげる → 移⾏の出発点は、情報をAI前提の形に変えること 50 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
51. 事例紹介：既存プロセスとの相互運⽤性が重要 01 変換後のテキストからExcelへ 逆変換できるようにする 02 これにより、既存プロセスの ⼤きな変更を避けられる 03 現場の受け⼊れコストを下げな がら、AI活⽤の⼟台を作れる → 既存業務を⽌めずにAI活⽤できる経路を作ること 51 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
52. 事例紹介：成果の数値化と体験が、変⾰を後押しする 01 AI活⽤の成果を計測する 02 ROIを算出‧可視化する 03 効果の実感と体験機会を広げる 04 その結果、 プロセスの変⾰の検討⼟台ができる → 効果が⾒えないと変⾰は進みにくい → 可視化が、次の意思決定を可能にする 52 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
53. 事例紹介：移⾏プランを⽴て、責任構造を壊さず進化させる 既存の責任構造を ⼀気に壊さない でも、AIが効く形へ 少しずつ変えていく 情報、仕組み、計測、 意思決定をつなげる → ソフトランディングを⽬指すなら → 責任を壊さずに、責任構造を進化させること 53 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
54. 事例紹介： 開発組織の「AI適応」のための取り組み内容 AI活⽤ポイントの⾒極め 理解負債などの落とし⽳の理解 ヒアリング、課題整理、移⾏プラン策定 移⾏プログラム‧プロンプトの作成 54 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
55. AI適応開発とは？ AIの⼒を最⼤限活かしつつ、⼈間が責任を持てる構造を設計する 組織の「AI適応」を推進するフレームワーク — 組織やツールの違いによらず、再現性の⾼い開発効率を実現 3つの柱 01 仕組み‧プロセス‧体制を AI前提に⾒直す 従来の開発プロセスや体制を AIの特性を活かす形に再設計し、 組織全体のパフォーマンスを最適化 02 責任を果たせる状態を 維持しながらAI活⽤を拡げる 決定論的ツールを組み合わせ、 AIだけに頼りきらない設計で 品質と説明責任を担保 03 考え⽅と設計の 枠組みを体系化 情報整理の⽅法‧判断基準を標準化 し、組織やツールが異なっても 適⽤可能な共通基盤を提供 その他の特徴 ISOやリスクマネジメント の⼿法がベース 組織学習サイクルを 組み込み、継続的に改善 実践知を体系化した リファレンス実装を同梱 55 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
56. AI適応開発は「理解負債」の課題を解決します AIの⽣成速度が⼈間の理解速度を超えることで「理解負債」が蓄積し、⼈間が疲弊する。 ── この課題に対し、プロセスを「⽣成AIに任せること」「⾃動化すること」 「⼈がやること」の3領域に整理し、それぞれの強みを活かす構造へ再設計します。 56 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
57. 01 成果物ベースでリスクを評価し、 対策（責任の果たし⽅）を選定 02 仕組み‧プロセス‧体制を ⼀体で⾒直す 03 AI / ⾃動化 / ⼈の3スコープで 任せ⽅を設計する → Shunkan AIでも、責任構造の再設計として取り組んでいます 57 弊社（Shunkan AI）におけるAI適応開発の取り組み事例 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
58. ハーネス（AI適応開発スターターキット）を設計‧構築する 1 情報をテキストでリポジトリ内に 保持する 2 DDD / レイヤードアーキテクチャで コンテキストを分離 3 SDD / BDD / TDDでAIの思考を統制 4 Linter / Formatter / Hooksによる 開発ルールの強制 5 AI⽣成ドキュメントの スキーマを設計し、⾃動検証 6 決定論的⽣成と 編集可/不可の領域分離 7 E2Eテスト⾃動化 （⽣成→実⾏→分析→修正のループ） 8 隔離環境と権限制御‧通信制限など のガードレール 9 開発ワークフローの スクリプト化による開発⾃動化 → ⽬的は、⾃動で保証できることを増やすこと 58 弊社（Shunkan AI）におけるAI適応開発の取り組み事例：仕組み 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
59. 弊社（Shunkan AI）におけるAI適応開発の取り組み事例：プロセス AI前提の開発プロセスを設計する 01 企画‧要件定義 02 プロトタイプ開発 03 本番開発 → 「企画‧要件定義」「プロトタイプ開発」「本番開発」の3フェーズに区切り、 フェーズごとに、AI活⽤を前提として求める成果物と責任の置き⽅を変える 59 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
60. 弊社（Shunkan AI）におけるAI適応開発の取り組み事例：プロセス 01 ほぼ完成版のモックアップを 早期に作る 02 事業要件‧業務要件の検証を 前倒しする 03 リスクの少ない技術スタック （HTML+CSS+VanillaJS）で レビューを省⼒化 → 前倒し検証の⽬的は、後⼯程の⼿戻りを減らすこと 60 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！ 企画‧要件定義では、前倒し検証を重視
61. 弊社（Shunkan AI）におけるAI適応開発の取り組み事例：プロセス 01 モックアップを分析して設計書を作る 02 設計書から定型コードを⾃動⽣成する 03 要件‧設計の意図を可能な限りテストで管理する 04 新規開発中は⼤きな差分や短時間マージも許容する → ユーザー影響が⼩さいプロトタイプ開発フェーズでは、 ハーネスを整備したことで問題は後から修正可能と判断し（OpenAIと同じ意思決定をして） 、 細部の理解よりも開発速度を優先 61 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！ プロトタイプ開発では、開発速度を優先
62. 弊社（Shunkan AI）におけるAI適応開発の取り組み事例：プロセス 01 機能要件だけでなく、 ⾮機能要件を強化‧検証する 02 ハーネスで保証される範囲と 保証されない範囲を再確認する 03 ハーネスで未保証の領域は、 情報整理‧リファクタリング‧ 追加検証で補う → 本番開発の⽬的は、品質を強化し、理解負債を解消し、保証範囲を拡⼤すること 62 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！ 本番開発では、品質強化と保証範囲拡⼤
63. 弊社（Shunkan AI）におけるAI適応開発の取り組み事例：体制 責任の種類‧範囲‧重さで開発フェーズを区切り、体制を変える 01 企画‧要件定義は、 少⼈数で⼀気通貫に進める 02 プロトタイプ開発も、 少数のエンジニアが広く担う 03 本番開発は、責任‧納期‧予算 に応じて必要な体制を組む ※責任構造の設計、組織的合意が、 体制‧納期‧予算の⾒積もりに影響 する → AI時代は、従来の役割分担の前提から⾒直すべき （01 と 02 は「複数専⾨家による分業」から「AI + 少数専⾨家」に変えた） 63 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
64. AI適応開発スターターキットの⽤意（Shunkan AI式のハーネス実装） 64 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
65. 知識と成果物を3つの対等なレイヤーに分離し、変化の頻度に応じて管理する harness/ 開発のルールブック How どう作るか【⽐喩: 建築基準法‧施⼯規則】 •コーディング規約‧命名規則 •API設計‧認証‧セキュリティ •フック‧エージェント‧スキル定義 •JSON Schema (バリデーション⽤) spec/ プロダクトの設計図 What 何を作るか【⽐喩: 設計図⾯‧施⼯図】 •ER定義 (DB設計) •OpenAPI (API仕様) •UIモックアップ‧要件書 •→ コード⽣成の⼊⼒元 issue_registry/ 開発の記録簿 What happened 何が起きたか【⽐喩: 施⼯⽇誌‧検査記録】 •状態駆動ワークフロー •不変レジストリ（削除なし） •完全な監査証跡 •アトミック操作 変化の頻度: harness ≒ 不変（詳細化は⽇々実施） ｜ spec ≒ 設計時に変化 ｜ issue_registry ≒ ⽇々変化 ※ 変化頻度の違いがディレクトリ分離の根拠 → spec変更がissueを完了させ、issueからspec作業が⽣まれる ドキュメント管理の3層構造: harness / spec / issue_registry 65 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
66. harness/ がルールを定め、spec/ と issue_registry/ がそれに従って連携する harness/ ルールブック •「ER定義はこのスキーマに従え」 •「generated/ は編集禁⽌」「コード⽣成は make generate-domain を使え」 ルールに従って ルールに従って spec/ 設計図 •er-definition.yaml •openapi-api.yaml •openapi-page.yaml ↓ make generate-domain ↓ app/domains/*/generated/ issue_registry/ 記録簿 •ISSUE-YYYYMMDD-NNNNNN.json •状態遷移: candidate → confirmed → fixing → fixed •「この要件を実装中」 •「このバグは修正済み」 Issue から spec 作業が⽣まれ、spec 変更が Issue を完了させる — 双⽅向の循環で開発が進む ※ ID相互参照: Issue側は requirement.spec_ref で spec を参照。ID体系: ISSUE-YYYYMMDD-NNNNNN vs REQ-domain-NNN ドキュメント管理の3層の連携フロー 66 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
67. harness/ のルールをプログラム的に強制するガードレール ユーザー操作 PreToolUse ツール実⾏ PostToolUse ... Stop → → → → → PreToolUse 事前検査 ルール違反をブロック •protect-generated generated/ への編集をブロック •protect-issue-registry cases/ への直接編集をブロック •enforce-uv-run python 直接実⾏を検知→ uv run 強制 PostToolUse 事後処理 品質を⾃動維持 •auto-lint ruff check/format を⾃動実⾏ •validate-yaml YAMLの⾃動バリデーション •spec-change-notify make generate-domain をリマインド •index-rebuild ほか Stop セッション終了 作業の棚卸しと同期確認 •post-session-summary 作業サマリーを⾃動⽣成 •check-doc-sync ドキュメント同期を確認 •check-test-sync テスト同期を確認 •auto-commit-reminder 未コミット変更をリマインド harness/ が「ルールの宣⾔」 → hooks/ がその「⾃動強制」を担当 ※ 終了コード: 0=続⾏、2=ブロック。stdin からツール名‧パラメータを JSON で受け取る hooks/ — ⾃動実⾏フック 67 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
68. ユーザーが /skill-name で呼び出すコマンド＆エージェントが内部参照するナレッジベース specify（要件定義） plan（計画） tasks（分解） implement（実装） → → → 3つのスコープ: /project-* /domain-* /feat-* ワークフロースキル •specify → plan → tasks → implement の4フェーズ × 3スコープ •+ モックアップ活⽤設計 (ER/API/Page) •+ ⾃動実⾏版 /auto-dev-* Issue Registry スキル •/issue-registry-create-* •/issue-registry-search, show •/issue-registry-start-task •/issue-registry-finish-task E2E テストスキル •/e2e-run テスト実⾏ •/e2e-generate コード⽣成 •/e2e-analyze 結果分析 •/e2e-fix 失敗テスト修正 オーケストレーション •/auto-dev-status, pause, resume •/auto-dev-parallel 並列開発 •/auto-dev-self-correct ⾃⼰修正 •/goal-decompose MECE分解 •/ralph-loop-input Ralph Loop ⼊⼒最適化 リファレンススキル •プロジェクト構造の理解 •コーディングパターン集 •評価フレームワーク ⾃動実⾏版 (/auto-dev-*) 各WFに対応 •ユーザー版: 対話的に進⾏ •⾃動実⾏版: ⾃律的に実⾏ •→ 同じワークフローの2モード harness/ のルールに従い、issue_registry/ と spec/ を⼊出⼒とする 「再利⽤可能な開発パイプライン」の⼀部としてスキルを設計 ※ SKILL.md にフロントマター (name, description, allowed-tools) + Markdown本⽂で定義 skills/ — エージェントスキル定義 68 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
69. コードジェネレーター（スキャフォルディング実装） Makefile（⼀部抜粋） ER図 / OpenAPI仕様書 make generate サーバーサイド⾃動⽣成： ✓ API ✓ ページコントローラ ✓ モデル ✓ サービス ✓ 各種テストコード ✓ 各種カスタム領域スタブコード クライアントサイド⾃動⽣成： ✓ JSクライアント ✓ JSクライアントテストコード 69 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
70. 仕様書 (spec/) から⾻格を⾃動⽣成し (generated/)、AIはビジネスロジックだけを書く (custom/) 4層アーキテクチャ（上位→下位のみ依存） Presentation Layer HTML Template / HTTPルーティング — custom/{apis,pages} に処理委譲 Service Layer ビジネスロジック — ドメイン固有の処理を実装 CRUD Layer データアクセス — 汎⽤ CRUD + カスタムクエリ Models Layer データ構造 — SQLAlchemy + Pydantic、ロジックなし ↓ ↓ ↓ generated/ と custom/ の分離 generated/ ⾃動⽣成（編集禁⽌） •カラム定義‧テーブル名‧制約 (SQLAlchemy) •OpenAPI スキーマからフィールド定義 + バリデーション (Pydantic) •汎⽤ CRUD ラッパー + ファクトリ関数 •ルーティング定義 → custom/{apis,pages} に委譲 ↓ 継 承 custom/ AIが書く（編集許可） •計算プロパティ‧カスタムバリデーションメソッド •ドメイン固有のクエリメソッド追加 •ビジネスルールのオーバーライド •エンドポイントの実処理（レート制限等） 各レイヤーで generated が⾻格、custom がビジネスロジック — ファクトリパターンで custom 優先 ※ ドメイン × 4レイヤー。テストも同構造で generated/custom 分離 70 レイヤードアーキテクチャ + generated/custom 分離 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
71. spec/ の YAML → Jinja2 テンプレート → generated/ のコードを⾃動⽣成する流れ spec/ ⼊⼒元 er-definition.yaml DB設計 openapi-api.yaml API仕様 openapi-page.yaml ページ設計 shared-types.yaml 共有型定義 → generators/ 変換 database_core.py DB設計 → Models + CRUD api_core.py API仕様 → APIs + Pydantic service_core.py DB設計/API仕様 → Services page_core.py ページ設計 → Pages → generated/ 出⼒ models/database/*.py + crud/ SQLAlchemy + CRUD apis/*.py + models/api/*.py Router + Pydantic services/*.py サービスクラス pages/*.py ページモジュール 実⾏: make generate-domain DOMAIN=auth | ⽣成順序: database → api → service → page 鉄則 •generated/ は編集禁⽌（フックでブロック）— カラム追加‧API追加は spec を変更して再⽣成 •custom/ に mapped_column やフィールドの追加は禁⽌ — スキーマ不整合‧OpenAPI 乖離の原因 ※ Jinja2 テンプレート (generators/core/templates/) で⽣成。テストも同構造で generated/custom 分離される 71 コード⽣成パイプライン 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
72. まとめ 2026-03-30 ©Ryohei Kamiya 72
73. AIを後付けするだけでは、⽣産性向上は限定的になりやすい 既存の仕組み‧プロセス‧体制がそのまま AIだけ追加しても、⼈⼿確認の負荷は残る 結果として、レビュー負荷や⼿戻りが増えやすい → AIツールの導⼊だけでは、期待した⽣産性向上は起きにくい 73 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
74. AI時代の課題は「⼈間がボトルネックになる」こと 01 AIの⽣成速度に、⼈間の 理解‧判断が追いつかない 02 ⼈間が細部を全部確認する 前提では回らない 03 だから、理解‧判断の負荷を 仕組みで減らす必要がある → ボトルネック解消には、ハーネスの整備が効く 74 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
75. ハーネスだけでは解決しない。「責任構造の再設計」が必要 01 仕組みだけ整えても、責任の境界は ⾃動では決まらない 02 何を保証し、何を⼈が承認するかを 決める必要がある 03 そのためには、仕組み‧プロセス‧ 体制を⼀体で⾒直す必要がある → 必要なのは、組織的な意思決定‧判断であり、そのための責任構造の再設計である 75 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
76. AI適応開発は「責任構造の再設計」の枠組みを提供 01 成果物ベースで情報を整理する 02 リスク評価に基づいて、 責任の置き⽅を設計する 03 その設計を、組織的な 意思決定につなげる → AI適応開発は、責任構造の再設計‧組織的意思決定に役⽴つフレームワークを提供 76 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
77. 仕組み‧プロセス‧体制の硬直化を防ぎ、AI の進化と事業環境変化に柔軟に適応する組織を⽬指す ハーネスの継続改善（⽇常） これからのエンジニアの仕事 = コードを書くのではなく ハーネスを整えること（by OpenAI） 組織学習サイクル（定期＋トリガー） ハーネスだけでなく「責任構造」全体を⾒直す → より広い組織的意思決定の⾒直し どの仕組み（ハーネス）に 何の責任を担わせるか どのプロセスで どんな責任を果たすか 誰が‧どのチームが 何の責任を担うか 定期点検 — ⾒直しの5アクション ＋ 成果物をリストに追加 − 削減可能な成果物を削除 ⇄ 成果物の分割‧統合 ⚡ リスク評価の⾒直し 🛡 対策の⾒直し 頻度: 初期は最低でも週1回（関係者が集まり集中実施） 安定期: エージェント⾃律性の向上に応じて間隔を延⻑ ⾒直しトリガー 障害発⽣時 インシデント対応後にリスク評価と対策を即時⾒直し プロジェクト開始‧終了時 成果物の追加‧削除‧統合と振り返り 改善提案時（任意） チームメンバーからの提案を随時受付‧反映 AI技術の進化時 新技術による責任構造の再設計機会を評価 ⾒直しの習慣化 → 仕組み‧プロセス‧体制の硬直化を防ぎ「AI適応⼒」の⾼い組織へ ※ 出典: OpenAI「Harness engineering」— エンジニアの仕事はコードではなくハーネスを整えること 重要：「組織学習サイクル」の設計と運⽤ — 責任構造の定期⾒直し 77 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
78. 従来⽐ 安定的に10倍以上（トップラインは100倍以上）の開発効率を⽬指す 1 責任構造の再設計⽀援 フレームワークを⽤いた情報整理 •成果物リストの整理 何を‧誰が‧どの仕組みで担うか •リスクアセスメント⽀援 成果物ごとのリスク評価 •対策提案 リスクに基づく具体的な対策設計 •組織学習サイクルの設計 2 ハーネスエンジニアリング⽀援 設計‧構築の助⾔ or 代⾏ •spec / harness / issue_registry 3層構造の設計と構築 •hooks / agents / skills .claude/ ⾃動化基盤の整備 •generated/custom 分離パターン コード⽣成パイプラインの構築 3 研修‧定着⽀援 開発現場での導⼊‧定着 •ハーネスエンジニアリング研修 チーム全員でハーネスを運⽤できる状態へ •AI適応開発プラクティス導⼊ 実プロジェクトでの伴⾛型サポート •組織学習サイクルの習慣化⽀援 定期⾒直しの仕組みを組織に定着 期間: 3ヶ⽉〜 料⾦: 個別ご相談 情報整理 + 設計‧構築 + 研修 の トータルパッケージ 「AI時代のシステム開発」を実現する仕組み‧プロセス‧体制づくりを⽀援しています 詳細が気になる⽅は、各種SNS ( X / Facebook / LinkedIn )のDMなどでお気軽にご連絡ください ※ ⽀援内容‧期間‧料⾦はご相談内容に応じて個別にご提案いたします 弊社（Shunkan AI）サービス紹介：開発組織のAI適応⽀援 78 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
79. AI適応診断 ⾃社の「AI適応⼒」が気になる⽅へ 「AI適応⼒」を簡易診断 ✓ ⾃社の AI適応 のレベルが気になる ✓ ⾃社のAI活⽤の改善可能性を知りたい ✓ 組織的にAI活⽤を進めるヒントがほしい 診断結果はメールでお届け ∕ 希望者はオンライン相談も予約可能 AI適応診断 https://adapt.shunkan.ai/s/shindan 79 2026-03-30 ©Ryohei Kamiya ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
80. 最後に、AI活⽤に向き合う同⼠の皆さんへ 01 AIの進化と普及により、 多くの産業が⼤きく変わり始めている 02 特にIT業界は、 その影響を最も⼤きく受ける業界の⼀つ 03 だからこそ、AI活⽤に向き合う私たちは、 変化を待つ側ではなく作る側に回れる → 激動の荒波をともに乗りこなし、 業界‧社会をより良いものにしていきましょう！ ©Ryohei Kamiya 80 2026-03-30 ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！
81. 質疑応答（ X で #bpstudy を確認 ） 2026-03-30 ©Ryohei Kamiya 81
82. Thank you! 82 2026-03-30 ©Ryohei Kamiya ともに、AIの荒波を乗りこなそう 神⾕ 亮平 ｜ Shunkan AI株式会社 取締役CTO BPStudy#223 𝕏 @k38ryohei お気軽にフォローしてください！ ご質問‧ご感想は #bpstudy をつけて X で投稿をお願いします！