AI_DevEX2026登壇資料.pdf

by smaregi_recruit

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

AI を思い通りに制御するための 3 層のハーネスの作り方 AI が迷うことを減らし、短い距離で正解へ導くための設計株式会社スマレジ石渡弘将

Slide 34

Slide 34 text

石渡弘将（わたり @rapicro） ● 株式会社スマレジ ○ ● ● 開発本部プロダクト推進チーム ○ 現在はPOSシステム開発中心活動 ○ PHPカンファレンス関西コアスタッフ他趣味 ○ ゲーム全般 ○ 甘い物 ○ カメラ ○ ガチャガチャ

Slide 35

Slide 35 text

目次 01 解決したい課題と基本方針 02 3 層のハーネスの全体像 03 物理層：コードそのもの 04 運用層：AI エージェント 05 ガバナンス層：人による評価と改善 06 現場導入へのステップ

Slide 36

Slide 36 text

結論ループを支えるのは、 3 層の「ハーネス」物理層 × 運用層 × ガバナンス層ループが大きく回るほど、AI の迷いも増幅される。鍵は指示の量ではなく、コード・AI・人の 3 層への情報配置。

Slide 37

Slide 37 text

ループを回し始めて、実際に起きたこと 01 ループが空回りし、AI が正解へたどり着かない 02 ベテランがやると動くが他のメンバーがやるとうまくできない 03 メンバー間の格差は広がるが埋め方がわからない

Slide 38

Slide 38 text

基本方針：余計なことは書かない AI に期待通りのコードを出させる前提は、迷わせないこと良かれと思って足した指示が、別の場面で挙動を狂わせることがある指示の「量」より適切な「場所と責務」

Slide 39

Slide 39 text

3層のハーネスで制御する AI の制御は指示や設定だけではなく、レイヤーごとに責務を分ける。 1 2 3 物理層運用層ガバナンス層コードそのものドメインモデルクラス構造コメント → AI エージェント AGENTS.md Skills ループ → 人による評価 /調整レビュー他の層の改善

Slide 40

Slide 40 text

物理層コードそのもの

Slide 41

Slide 41 text

物理層コードそのもの ✓ 回避されづらい基本的なハーネス ✓ AI エージェントの種類に左右されない ✓ 作業箇所に最も近い ✓ 関連しない作業のコンテキストを汚染しない

Slide 42

Slide 42 text

物理層物理層で目指す状態 Project as Code: コードを「仕様」に近づけるドメインモデルの強化 AIが関連ファイルを探索しなくても、コード構造や周辺コメントから仕様が自明な状態を作る判断の理由となる 1次情報を記載するコメントで外部API仕様書へのリンクを記載するなど、設計の「なぜ」を記載し逸脱を防ぐ仕様が先にあり、それをコードに反映する ※「今動いているものを仕様とみなす」のではない

Slide 43

Slide 43 text

物理層技術的負債への向き合い方負債はAIの「視界」を曇らせるレガシーなコードはAIにとって「誤ったコンテキスト」として作用する。利用拡大を避けたいなら「Deprecated: 非推奨」の記載や To-Beの記載によって正しい方向を示す。 AIは負債も増幅するが、方向性があれば改善する。

Slide 44

Slide 44 text

運用層 AI エージェント

Slide 45

Slide 45 text

運用層 AI エージェント制御コードだけで表現しづらいものを扱うレイヤー。ただし、コンテキストを汚染しないように適切な場所へ隔離する。 ※下記名称は Codex / Claude Code の例だが、多くのエージェントに相当機能がある。 AGENTS.md: ディレクトリごとの役割オーケストレーション : 役割毎の分担処理 Skills: 構造を超えた指示 hooks: 実行前後のガードレール

Slide 46

Slide 46 text

運用層場所と責務を押さえてコンテキストを抑える「本当」を増やすより「嘘」を減らすコンテキストは増えると薄まる AIにコンテキストを渡せたからといってそれらを全て守ってくれるわけではない AIに任せると量だけが増える AIが分かっていることを書かせると、なくてもAIが分かる情報だけが増えやすい 1行の嘘は千行の嘘になる間違った1行を前提にAIは千行のコードを生成し、間違いが増幅される

Slide 47

Slide 47 text

運用層 AGENTS.md の配置例グローバル（ホームディレクトリ）個人PC内全体 ~/.codex/AGENTS.md リポジトリルート共通ルール・共有資産 /AGENTS.md サブディレクトリ近い指示・汚染を防ぐ /xxx/AGENTS.md チーム共通ルールはリポジトリ内に置いて資産化。

Slide 48

Slide 48 text

運用層 Skills AGENTS.md だけでは扱いにくい、動的な判断やまとまった手順を切り出す。明示的に呼び出すスキル暗黙的に呼び出すスキルまとまった作業手順として使うタスク内容から必要性を判断する例：レビュースキル・ブランチ名から Issue を取得する・仕様と実装が合っているか確認する・レビュー観点に沿って指摘を出す用途・AGENTS.md では粒度が合わないもの・特定の作業種別でだけ効かせたいもの・共通化したいが常時適用したくないもの例: DDDで同様の構成が並列で存在する場合に有用暗黙呼び出しを切ることで、呼び出し時以外はコンテキストに関与しない段階的開示とはいえ、関係ない作業でも常にコンテキストを食うので用途を絞る

Slide 49

Slide 49 text

運用層 hooks AI に「守ってほしい」と頼むのではなく、実行前後に決定的な処理を差し込む仕組み。実行前 PreToolUse 例: 危険なコマンドを検査する実行後 PostToolUse 例: 変更後のファイルチェックを走らせる完了前 Stop 例: 応答完了時に全体にカスタムバリデーションを実行する

Slide 50

Slide 50 text

運用層オーケストレーション機構 /goalコマンド、 TAKTなど検証と修正の自律サイクルにより、大規模開発でも設計の一貫性と品質を担保する仕組みループ終了の目印となるゴールの設計やハーネスが重要 AIが自律的に大きく動くことで良いところも悪いところも増幅される AGENTS.mdやSkillsなどの土台を作り出力を安定化することが必要

Slide 51

Slide 51 text

ガバナンス層人による評価と改善

Slide 52

Slide 52 text

ガバナンス層人による評価と改善オーケストレーションを実行して終わりではない。最終的な品質保証は人が行う。 1 実際の出力を評価し、設計意図とズレていないか見る ↓ 2 期待とズレた理由を分析する ↓ 3 設計、指示・ハーネスのどの部分かなど、どこでどう制御すべきか見直す

Slide 53

Slide 53 text

実際にあった失敗例あるメンバーが内容的には xxx/service を修正してほしい状況で、 AI が xxx/templates を変更してその場しのぎの対応をした。 ▼ 修正し、対策として「再発防止して」とAIに指示。 AIがホームディレクトリのスキルに「xxx/service を優先的に変更する」と書いた。 ▼ 次のタスクでは、要件は満たすもののコード配置がおかしい変更が発生。レビューにより「AIの指示がおかしいのでは？」とホームディレクトリのスキルが発覚。

Slide 54

Slide 54 text

実例この失敗に、 3層でどう対処したか発見はレビューから。対処を適切な層へ配置した。 1 ガバナンス層（人）：レビューで「コードの配置がおかしい」と気づき、原因がホームディレクトリの指示だと特定した ↓ 2 運用層（AI エージェント）：ディレクトリの AGENTS.md に責務を記載し、個人環境ではなくリポジトリ内で共有する形にした ↓ 3 物理層（コード）：その場しのぎの変更を、ドメインモデルを意識した形のコードへ修正（この層の対処は最小限で済んだ）

Slide 55

Slide 55 text

ガバナンス層メンバーの技術力向上スキル格差も「増幅」される。見る対象を「 AIの使い方」へ変え、チームで共有する。レビュー細かいアルゴリズムより、設計と指示をみるソフトウェアチーミング（モブプロ）リーダーやメンバーも含め互いのAIの使い方を見せ合う輪読会本や記事をきっかけに共通認識を作り方向性を統一する

Slide 56

Slide 56 text

まとめ： 3 層の使い分けレイヤー役割例物理層（コード）仕様をコードに埋め込むドメインモデル、責務分離、 Deprecated 運用層（AIエージェント） AI へ作業ルールを渡す AGENTS.md、Skills、 hooks、オーケストレーションガバナンス層（人）出力を評価し調整するレビュー、評価ループ AI制御とは、指示を増やすことではなく、情報を適切な層へ配置すること

Slide 57

Slide 57 text

Takeaway AIを制御するとは、指示を増やすことではない。 AI が迷わず正しい判断へ進めるように、情報を適切なレイヤーへ配置することである。

Slide 58

Slide 58 text

【非公式】 AI DevEx Conference 2026 スマレジセッション深掘り会 We are Hiring! メンバー募集中！カジュアル面談も大歓迎詳細はQRコードから！ 2026年8月26日(水) 19:00~ ※オンラインご清聴ありがとうございました Thank you for your attention