更新日: 2026-07-13
AIによって、エンジニアが扱える範囲は広がった。
従来は実装経験を中心に説明すればよかったが、現在は次の工程まで一人で扱える。
- ビジネス課題の調査
- 要件整理
- 技術選定
- 実装
- テスト
- コードレビュー
- 顧客説明
- 運用手順の作成
- 障害対応
- 改善計画
一方で、面接時間と面接官の認知容量は増えていない。
AIツール、プロンプト、エージェント制御、アーキテクチャ、DDD、セキュリティ、テスト、運用を一度に説明すると、候補者が何を判断できる人なのかが見えにくくなる。
そのため、職務経歴書、スキル欄、面接では、知っている技術をすべて説明するのではなく、次の流れを再現できることを示す。
ビジネス課題
→ 制約と優先順位
→ 技術的な問題構造
→ 既知の前提と未知の論点
→ 選択肢とトレードオフ
→ 調査・再現・切り分け
→ 工程分割
→ 工程ごとのAI作戦
→ 実行結果と作戦変更
→ 設計品質の作り込み
→ リリース品質の保証
→ 説明
→ 導入・運用・撤退
このガイドラインでは、職務経歴書を「経歴の一覧」ではなく、面接で共有する前提条件と評価プロトコルとして扱う。
面接で評価する中心は、生成されたコードの量ではない。
工程をどう分けたか。
未知を、確認済みの事実、仮説、次の確認へどう変換したか。
各工程でAIへどの作戦を与えたか。
結果を見て、続行、停止、追加調査、作戦変更、人間への差し戻しをどう判断したか。
次のような記述だけでは、何を任せられるか判断できない。
- PHP経験10年
- Symfony経験5年
- ChatGPTを利用
- EC-CUBEのカスタマイズ経験
- DDDを学習
技術名は、判断能力の証拠として使う。
中心に置くのは、次の内容である。
- どの課題を扱ったか
- 何を優先したか
- 工程をどう分けたか
- どの案を採用したか
- 何を採用しなかったか
- 各工程でAIへ何を許可したか
- どの結果を受けて作戦を変えたか
- どこを人間が監査したか
- どう検証したか
- 誰にどう説明したか
- 問題時にどう戻したか
AI利用をコード生成だけで説明しない。
AI支援開発は、案件全体で一つの指示を与えるのではなく、工程ごとに作戦を変える。
各工程について、次の6項目を記録する。
- 工程の目的
- AIへ与えた作戦
- AIへ許可した操作
- AIへ禁止した操作
- 得られた結果
- 次工程へ進む条件、停止条件、作戦変更条件
調査段階では、既存コードの読取と関連箇所の列挙だけを許可した。
ファイル変更、外部コマンド実行、依存追加は禁止した。
調査によって決済と在庫への影響が判明したため、自律的な試作へ進まず、人間による業務設計へ戻した。
AIが担当した作業と、人間が保持した判断も分ける。
- 情報探索
- 未知の論点と確認項目の整理
- デバッグ手順と切り分け候補の作成
- 既存コードの調査
- 選択肢の列挙
- 定型コードの生成
- テストケース候補の抽出
- 静的解析エラーの整理
- 差分の要約
- 説明資料の初稿
- 運用手順の雛形
- ビジネス課題の定義
- 制約と優先順位
- 工程の分割
- 業務ルール
- 責務境界
- 品質水準
- AIへ与える権限
- 監査範囲
- 受入条件
- 採用・不採用判断
- 作戦変更
- 仮説の採用・棄却
- 調査を打ち切る条件
- 顧客へ確約する範囲
- リリース判断
- 撤退判断
AIへの作戦とは、短い命令文や人格設定ではない。
次の要素をまとめた開発方針である。
- 目的
- 優先順位
- AIへ委譲する判断
- 許可する操作
- 禁止する操作
- 確認方法
- 停止条件
- 人間へ判断を戻す条件
ドラクエの作戦名は、この方針を覚えやすくする補助語彙として使う。
| 業務上の名称 | 作戦の比喩 | 方針 |
|---|---|---|
| 探索優先 | いろいろやろうぜ | 選択肢、影響範囲、不明点を広く調べる |
| 試作優先 | ガンガンいこうぜ | 隔離環境で素早く形にして実現可能性を確認する |
| 指示固定 | めいれいさせろ | 人間が設計、変更範囲、実装順序を指定する |
| 定型委譲 | みんながんばれ | 確定した規約と受入条件の範囲でAIへ実装を任せる |
| 安全優先 | いのちだいじに | 副作用、異常系、可逆性、復旧を優先する |
| 実行制限 | じゅもんつかうな | 書込み、外部接続、依存追加、本番操作などを禁止する |
面接では、最初に業務上の名称を使い、必要に応じて作戦の比喩を補足する。
最初の指示が完全であることを前提にしない。
AIから得られた結果を確認し、続行、停止、作戦変更、人間への差し戻しを判断する。
次の状況では、人間へ判断を戻す。
- 変更範囲が想定より広がった
- 業務ルールが不明確だった
- 複数の正解候補が残った
- データ変更や外部送信が必要になった
- 認証、決済、個人情報へ影響した
- テストで再現できない挙動が発生した
- 既存仕様とコードが一致しなかった
- ロールバック方法を定義できなかった
- AIが前提条件を推測で補っていた
- 受入条件を満たしているか自動判定できなかった
作戦変更は、次の形式で記録する。
当初の作戦
→ 観測された結果
→ 問題になった条件
→ 変更後の作戦
→ 人間が引き取った判断
AI制御能力は、最初から正しい指示を書けることではない。
結果を観測し、権限と作戦を調整できることである。
未知の技術や原因不明のバグに遭遇したとき、AIへ原因の断定を求めない。
未知を次の要素へ分ける。
- 観測済みの事実
- 未確認の情報
- 原因または実現方法の仮説
- 仮説を確認する方法
- 仮説を棄却する条件
- 次工程へ進む条件
- 調査対象を変更する条件
- 人間または顧客へ判断を戻す条件
デバッグでは、次の順序を基本にする。
現象と期待値の確認
→ 再現条件の固定
→ 影響範囲の切り分け
→ 仮説の設定
→ 一度に一条件だけ変更して観測
→ 原因候補の採用または棄却
→ 最小修正
→ 回帰確認
AIには、原因そのものより、次に行う確認作業と、各確認によって何が分かるかを提示させる。
調査結果は次の形式で記録する。
観測した事実
→ 現在の仮説
→ 次の確認
→ 確認結果
→ 仮説の維持、棄却、または追加調査
AIが根拠を示せない場合や、リポジトリ固有の実装を理解していない場合は、実装を継続させない。
公式仕様、実装コード、テスト、既存Issue、変更履歴、リポジトリ固有の資料、DeepWikiなどへ調査対象を移す。
未知への対応力は、すべてを知っていることではない。
分からない状態を、確認可能な小さな作業へ変え、根拠を積み上げて次の判断へ進めることである。
動くコードを生成すること、保守可能な構造へ作り込むこと、リリース可能な品質を保証することは、別の過程として扱う。
| 過程 | 目的 | 主な評価対象 |
|---|---|---|
| 作る | 実現可能性と基本動作を確認する | 工程分割、AIへの指示、権限、停止条件 |
| 作り込む | 業務ルールとコード構造を整える | 責務境界、DDD、変更容易性、保守性 |
| 保証する | リリース可能な品質を確認する | セキュリティ、回帰、異常系、復旧、運用 |
- 現象と期待値の分離
- 環境情報と再現条件の固定
- 確認済みの事実と仮説の分離
- 一度に一条件だけ変更する切り分け
- 最小再現コードの作成
- 原因候補を棄却した記録
- 既存コード、仕様、既存Issueの調査
- 実現可能性の確認
- 最小構成の試作
- 基本的な正常系の確認
- 技術的な不明点の洗い出し
- 修正前後を比較するテスト
- 業務用語の整理
- 状態遷移の明確化
- 責務境界の整理
- ドメインモデルの設計
- 重複の解消
- 判断の流出の解消
- 変更容易性の改善
- テスト可能性の改善
- 認証・認可
- 異常系
- 二重実行
- 部分失敗
- 回帰
- ログ
- 監視
- 復旧
- ロールバック
- 運用手順
- リリース判断
AIによってController、Service、Repository、DTO、テストが生成されても、ドメイン設計が適切であることは証明されない。
作る段階の評価と、設計品質の評価を分ける。
ただし、認証方式、権限モデル、個人情報の保存場所、決済処理の境界など、後から変更しにくい前提は、作る前に決める。
すべての案件へ同じ品質水準を適用しない。
プロトタイプ、社内ツール、短期キャンペーン、決済処理では、必要な品質が異なる。
品質水準は、次の条件から決める。
- 利用者数
- 利用期間
- 障害時の影響
- 扱うデータ
- 金銭への影響
- 外部サービスとの連携
- 復旧可能性
- 変更頻度
- 保守期間
面接では、常に最高品質を目指すと答えるのではなく、どの領域へ先に品質投資するかを説明する。
後回しにした設計課題には、改善条件または撤退条件を付ける。
AI生成コードをすべて一行ずつ確認する運用は成立しない。
人間の監査資源は、重大事故につながる境界へ集中する。
監査範囲は、次の6項目で決める。
- 権限
- 守る資産
- 副作用
- 可逆性
- 検知可能性
- 被害範囲
- 認証・認可
- 決済・返金
- 個人情報
- 在庫
- 受注状態
- 会計
- データ削除
- 一括更新
- マイグレーション
- 外部APIの更新処理
- ファイルアップロード
- 本番バッチ
- ログへの機密情報出力
- コードスタイル
- 型
- Lint
- ビルド
- 定型的な表示変更
- 既存テストで覆われた処理
- 破棄可能なプロトタイプ
ただし、ファイル種別だけで判断しない。
テンプレート変更でも、個人情報表示、URL生成、raw 出力を含む場合は監査レベルを上げる。
セキュリティと安全性を、一度の確認で済ませない。
- 本番環境へ接続しない
- 実データを使用しない
- 秘密情報をコードへ書かない
- 認証や認可を迂回しない
- DB変更を自動実行しない
- 外部サービスへ実送信しない
- 新規依存を無断で追加しない
- 削除や一括更新を停止条件にする
- 権限変更を自動承認しない
- 生成された設定をそのまま本番へ適用しない
この段階の目的は、危険な試作を作らせないことである。
- 認証・認可の境界確認
- 入力改ざんの確認
- CSRFや権限不足の確認
- 二重送信と二重実行
- 通信切断と途中失敗
- 依存ライブラリの確認
- 機密情報を含むログの確認
- 回帰テスト
- ロールバック
- 手動復旧手順
- 監視と検知方法
- 本番相当条件での受入確認
この段階の目的は、失敗を検出し、停止し、復旧できることを保証することである。
職務要約では、技術スタックの列挙より、仕事の進め方を示す。
Web開発において、ビジネス課題、制約、技術的な問題構造を整理し、工程を調査、再現、切り分け、試作、設計、実装、検証へ分割する。
未知の技術や原因不明のバグは、観測済みの事実、仮説、次の確認へ分け、AIには原因の断定より確認手順の設計を支援させる。
各工程でAIの目的、権限、禁止事項、停止条件を設定し、結果を確認して続行、追加調査、作戦変更、人間への差し戻しを判断する。
AIは既存コード調査、選択肢整理、定型コード生成、テスト観点抽出、説明資料作成に利用し、業務ルール、責務境界、仮説の採用、受入条件、監査範囲、顧客への確約、リリース判断は人間側で管理する。
コードだけでなく、作戦記録、調査ログ、最小再現、テスト、検証記録、顧客説明、運用手順を成果物として残す。
個別案件ごとに同じ工程を繰り返さず、職務経歴書の前半に共通ワークフローを置く。
- ビジネス課題を整理する
- 制約と優先順位を決める
- 技術的な問題構造を分解する
- 既知の前提、未知の論点、確認が必要な約束を分ける
- 選択肢とトレードオフを比較する
- 未知が主要な障害であれば、現象確認、再現、切り分け、調査へ分ける
- 開発工程を複数のステップへ分ける
- 各ステップの目的と完了条件を決める
- 各ステップのAI作戦、権限、禁止事項を決める
- AIには確認項目、比較条件、必要なログ、調査先を整理させる
- 実行結果を事実、仮説、次の確認として記録する
- 続行、停止、追加調査、作戦変更、人間への差し戻しを判断する
- 最小再現または最小構成を作り、原因や実現可能性を確認する
- AIの根拠が不足する場合は、公式仕様、実装コード、既存Issue、DeepWikiなどへ調査を移す
- 責務境界とドメイン設計を作り込む
- 自動検証と人間の監査範囲を分ける
- 納品前の安全性と運用可能性を検証する
- 顧客、経営者、開発者、運用担当者向けに説明を分ける
- 導入、監視、復旧、撤退方法を定義する
- 判断、調査手順、作戦変更を次回へ再利用できる形で記録する
各案件では、工程全体を繰り返さず、重要な判断と作戦変更を中心に書く。
何に困っていたか。
何を優先し、何を後回しにしたか。
どのデータ、状態、外部サービスが関係したか。
何が確認済みで、何が推測または未確認だったか。顧客へ確約できない事項は何か。
どの現象を再現し、何を一条件ずつ比較し、どの仮説を採用または棄却したか。
何を比較し、なぜその案を選んだか。
どのようなステップへ分けたか。
各ステップで何をAIへ任せたか。
読取、編集、コマンド実行、外部接続をどこまで許可したか。
AIから何が得られ、どの結果を受けて続行、停止、追加調査、変更を判断したか。根拠不足の回答をどの情報源で確認したか。
責務境界、ドメイン設計、保守性をどう改善したか。
セキュリティ、異常系、回帰、復旧をどう検証したか。
誰に何を説明し、どのように導入したか。未確定事項を顧客からどう持ち帰り、どの段階で確約へ変えたか。
注文キャンセルが、受注状態だけでなく、決済取消、在庫復元、ポイント、通知へ影響することを前提に工程を分割した。
調査段階では「探索優先」と「実行制限」を組み合わせ、AIには既存コード、イベント、PurchaseFlow、決済連携箇所の読取だけを許可した。ファイル変更、外部API実行、DB更新は禁止した。
調査結果から決済サービスごとに取消条件が異なることが判明したため、自律的な試作を止め、人間が状態遷移、冪等性、部分失敗時の運用を定義した。
設計確定後は、Controller、Service、FormType、テストの定型実装をAIへ委譲した。Controllerには入力と応答だけを置き、業務判断はServiceへ集約した。
納品前には、権限不足、二重実行、決済取消失敗、在庫復元失敗、通信切断、手動復旧を検証した。
顧客向けにはキャンセル可能条件と失敗時の運用を説明し、開発者向けには責務境界、拡張箇所、テスト結果を記録した。
未知のライブラリ内部挙動に関係する不具合について、最初から原因を断定せず、現象、期待値、環境、再現条件を整理した。
AIには修正コードではなく、切り分け手順、取得すべきログ、比較条件、最小再現から削除できる要素を列挙させた。
一度に一条件だけを変更し、各結果を観測済みの事実、現在の仮説、次の確認として記録した。
AIモデルだけではリポジトリ固有の実装根拠が不足したため、実装コード、テスト、既存Issue、変更履歴、DeepWikiへ調査を移した。
最終的に、最小再現コード、環境情報、期待する結果、実際の結果、再現手順を整理し、第三者が追試できるGitHub Issueとして報告した。
この経験から、原因不明の問題では修正より再現を優先し、AIの提案は実行結果または一次情報で検証する判断基準を再利用している。
- ChatGPT
- Claude
- Codex
- Symfony
- EC-CUBE
- PHPUnit
これでは利用範囲と責任範囲が分からない。
- ビジネス課題、制約、影響範囲の整理
- 開発工程の分割
- 工程ごとの目的、権限、禁止事項、停止条件の設定
- 既存コード調査、実装案比較、定型コード生成
- 未知の論点を事実、仮説、次の確認へ分割
- 再現条件、比較条件、必要なログ、調査先の整理
- AI出力に応じた続行、停止、追加調査、作戦変更
- テストケースと異常系の抽出
- 最小再現コードとGitHub Issueの作成
- 公式仕様、実装コード、既存IssueによるAI回答の検証
- 静的解析、自動テスト、手動確認による受入
- 顧客、経営者、開発者、運用担当者向け資料の作成
- 業務ルール、責務境界、受入条件、監査範囲、リリース判断は人間側で管理
app/Customize、Plugin、EventSubscriber、PurchaseFlowの適用判断- Controller、Service、Repository、FormTypeの責務分離
- 受注、在庫、決済、ポイント、メールへの影響分析
- 状態遷移、冪等性、部分失敗、復旧方法の設計
- 認可、CSRF、二重実行防止の確認
- PHPUnit、Playwright、PHPStanによる検証
- 顧客向け業務説明と開発者向け技術資料の作成
同じスキルを、相手の理解度に合わせて説明する。
ECサイトの変更が在庫や決済へ与える影響を整理し、事故を防ぐ。
調査、試作、設計、実装、検証へ分け、工程ごとにAIの権限を変える。
画面処理、業務処理、データアクセスを分離する。
Controller、Service、Repository、PurchaseFlow、EventSubscriberを責務に応じて使い分ける。
AIには工程ごとに読取、編集、コマンド実行、外部接続の権限を設定する。
最初からレベル3で説明しない。
面接では、複数のビジネス課題に対して、同じ判断手順を再現できるかを示す。
- ビジネス課題
- 制約と優先順位
- 技術的な問題構造
- 既知の前提と未知の論点
- 選択肢とトレードオフ
- 調査・再現・切り分け
- 工程分割
- 工程ごとのAI作戦
- 結果と作戦変更
- 設計品質の作り込み
- リリース品質の保証
- 人間の監査範囲
- 導入・運用・撤退
最初からプロンプト全文、クラス構成、フレームワーク固有の用語を出さない。
注文キャンセルを、調査、業務設計、定型実装、納品前検証へ分けました。
調査ではAIを書込み禁止にし、決済と在庫への影響を確認しました。
業務判断が必要になった段階でAIの自律実装を止め、人間が状態遷移と受入条件を決めました。
設計確定後の定型実装をAIへ任せ、最後に二重実行、部分失敗、復旧を確認しました。
面接官が設計詳細を求めた場合に、次を説明する。
Controllerを入力と応答に限定し、業務処理をServiceへ集約しました。
さらにEC-CUBE固有の質問があれば説明する。
EC-CUBEでは
app/Customize、EventSubscriber、PurchaseFlowを責務に応じて使い分けました。
- 課題
- 制約
- 工程分割
- 工程ごとの作戦
- AIの権限と禁止事項
- 結果
- 作戦の切替条件
第1パスでは、候補者が仕事を分解し、AIの自律度を調整できるかを確認する。
- 業務ルール
- 状態遷移
- 責務境界
- DDDやアーキテクチャ
- 採用しなかった設計
- 変更容易性
- テスト可能性
第2パスでは、動くコードを保守可能な構造へ作り込めるかを確認する。
- セキュリティ
- 異常系
- 回帰
- ログ
- 監視
- 復旧
- ロールバック
- 運用手順
- リリース判断
第3パスでは、完成した機能を安全に導入し、問題時に戻せるかを確認する。
- 課題
- 工程分割
- 工程ごとの作戦
- 作戦変更
- 最終検証
- 制約
- 問題構造
- AIの権限と禁止事項
- 実行結果
- 人間が引き取った判断
- 作り込み
- 保証
- 導入・撤退
- クラス構成
- 状態遷移
- ドメインモデル
- テスト
- セキュリティ
- ログ
- 運用
- AI制御
- 作戦変更履歴
- 調査ログと仮説の棄却履歴
- 一次情報へ調査を切り替えた理由
未知への対応を「AIに聞けば解決する」と説明しない。
次の順序で説明する。
- 何が未知だったか
- どの現象または顧客要求を確認したか
- 何を優先し、何を約束しなかったか
- AIへどの確認手順を作らせたか
- どの事実を観測したか
- どの仮説を棄却したか
- どの情報源へ調査を移したか
- 何を成果物として残したか
- 次回も使える判断基準は何か
未経験の技術や原因不明のバグでは、最初から原因を当てようとせず、現象確認、再現条件の固定、影響範囲の切り分け、仮説検証へ分けます。AIには答えの断定ではなく、次に確認すべき項目を出させます。結果を一つずつ記録し、必要なら公式資料、実装コード、既存Issue、DeepWikiへ調査を広げます。この方法で最小再現まで絞り込み、GitHub Issueとして報告した経験があります。
未経験分野やバグへの対応では、知識が不足していること自体より、何を確認すれば前進できるかを明確にすることを重視しています。
原因不明の挙動では、現象、環境、再現条件、期待する結果、実際の結果を整理します。そのうえで、AIには原因を断定させるのではなく、切り分け手順と、それぞれの確認によって何が分かるかを提示させます。
一度に一条件だけを変え、ログや戻り値を確認し、不要な要素を外して最小構成へ近づけます。AIの回答に根拠が不足する場合は、公式ドキュメント、対象リポジトリのコード、既存Issue、DeepWikiへ調査を切り替えます。
最終的には、環境情報、最小再現コード、期待値、実際の結果を第三者が追試できる形で残します。未経験でも何でも即答できるとは考えていませんが、未知を小さな確認作業へ分解し、根拠を積み上げて次の判断へ進めることは再現できます。
AIは案件全体へ一律に使うのではなく、工程ごとに役割を変えます。
調査では既存コードの探索と影響範囲の整理、試作では隔離環境での最小実装、設計確定後は定型コード生成、検証ではテスト観点と差分整理に使います。
業務ルール、責務境界、権限、受入条件、作戦変更、リリース判断は人間側で持ちます。
プロンプトの文面より、工程の目的、許可する操作、禁止事項、確認方法、停止条件を決めます。
たとえば調査では読取だけを許可し、試作では隔離環境内の編集とテスト実行だけを許可します。
業務ルールが不明な場合や決済、個人情報へ影響する場合は、自律実装を止めて人間へ戻します。
すべてを同じ深さでは確認しません。
権限、決済、個人情報、在庫、削除、外部API更新のような高リスク領域は人間が必ず監査します。
コードスタイル、型、定型的な表示処理は自動検証へ寄せます。
判断基準は、資産、副作用、可逆性、検知可能性、被害範囲です。
最初に評価するのは、工程分割とAIへの指示が適切か、最小構成で問題を再現できるかです。
業務ルール、状態遷移、変更頻度が明確になった段階で、責務境界やドメインモデルを作り込みます。
決済、認可、個人情報など、後から変更しにくい境界は最初に決めますが、すべての試作へDDDを適用することはしません。
開発中の安全制約と、納品前の保証を分けます。
開発中は本番接続、実データ、秘密情報、DB更新、外部送信を制限します。
納品前には認証、認可、入力改ざん、二重実行、通信切断、ログ、回帰、復旧を厳密に確認します。
認証方式や個人情報の保存場所などの前提は、作る前に決めます。
すべての案件へ同じ品質水準は適用しません。
試作品や社内ツールでは、まず動くものを作り、利用価値を確認します。
一方で、決済、個人情報、在庫、認可は初期段階から制約を設けます。
後回しにした設計課題には、改善または撤退の条件を付けます。
- 守る資産を特定する
- 重大事故を挙げる
- 必須監査範囲を決める
- 自動化する範囲を決める
- 受入条件を示す
- 復旧方法を示す
重要資産は、注文、決済、在庫、ポイント、顧客情報です。
決済取消、状態遷移、在庫復元、権限、二重実行防止は人間が監査します。
定型的な画面実装や型チェックはAIと自動検証へ寄せます。
決済失敗、通信切断、再実行、権限不足を受入試験に含めます。
問題時は自動処理を止め、手動運用へ戻せるようにします。
まず、実装に必要な前提、公式資料、最小構成、確認方法、失敗条件へ分けます。
AIには調査工程、確認項目、比較条件の整理を支援させますが、回答は実行結果、公式資料、実装コードで確認します。
業務ルールや安全性に関係する判断は、分からないまま実装せず、人間または顧客へ戻します。
原因の推測より、再現条件の固定を優先します。
確認済みの事実、仮説、次の確認へ分け、一度に一条件だけ変えます。
AIには切り分け手順、取得するログ、最小再現から削除できる要素を出させます。
修正前後をテストで比較し、必要に応じて第三者が追試できるGitHub Issueとして記録します。
その場で推測による回答、費用、納期を確約しません。
現在の運用、困っている現象、期待する状態、制約、期限、関係するシステム、判断者を確認して持ち帰ります。
その後、AIを使って確認事項、技術調査、選択肢、リスク、次回質問へ分け、実行結果や一次情報で確認したうえで回答します。
一つの成功事例だけでは、再現性を判断しにくい。
異なる性質の事例を三つ以上用意する。
各事例では、使用した技術を変えるだけでなく、工程と作戦の組合せを変える。
例：
- EC-CUBEの注文キャンセル
- 在庫連携
- 決済
- ポイント
- 予約管理
示す能力：
- 状態遷移
- データ整合性
- 部分失敗
- 二重実行
- 監査証跡
- 自律実装を止める判断
例：
- 問い合わせフォーム
- 資料請求
- CRM連携
- メール送信
- スパム対策
示す能力：
- 個人情報
- 入力境界
- 外部サービス
- 障害時の運用
- 顧客説明
- 開発中の外部送信制限
例：
- WordPress更新
- 表示速度改善
- セキュリティ対応
- PHP更新
- テスト導入
示す能力：
- 影響分析
- 品質基準
- 段階導入
- ロールバック
- 運用手順
- 調査と変更を分離する判断
例：
- データ整理
- 社内検索
- レポート生成
- 定型業務支援
示す能力：
- 品質水準の調整
- 利用範囲の制限
- 捨てる条件
- 本番システム化の境界
- 試作から作り込みへ移る条件
例：
- PHP拡張やライブラリの不具合調査
- WordPress更新時の互換性問題
- ブラウザ差異
- 外部APIの予期しない応答
- フレームワーク内部挙動の調査
示す能力：
- 現象と期待値の分離
- 環境と再現条件の固定
- 最小再現
- 事実と仮説の分離
- 一条件ずつ変更する切り分け
- AI回答の検証
- 公式仕様、実装コード、既存Issueへの移動
- 仮説を棄却した記録
- GitHub Issueの作成
- 第三者が追試できる説明
複雑な工程では、一つの作戦だけを使わない。
| 工程 | 作戦 | AIへの主な指示 | 得られる結果 |
|---|---|---|---|
| 調査 | 探索優先＋実行制限 | 関連コードを調査する。変更は禁止 | 状態遷移、依存先、不明点の一覧 |
| 試作 | 試作優先＋実行制限 | 隔離環境で試作。本番・実決済は禁止 | 実現可能性と技術的な問題 |
| 業務設計 | 指示固定＋安全優先 | 人間が状態遷移、冪等性、復旧方針を指定 | 実装可能な設計と受入条件 |
| 定型実装 | 定型委譲 | 確定した設計と既存規約に従って実装 | コード、テスト、ログ |
| 納品前検証 | 安全優先＋指示固定 | 異常系、二重実行、途中失敗を指定して検証 | 検証記録、残課題、復旧手順 |
評価するのは、どの作戦が最強かではない。
工程の性質に応じて、作戦を組み合わせ、切り替えられるかである。
- 制約は3点まで
- 工程は3から5段階に圧縮する
- 選択肢は2案、最大3案
- 作戦は工程ごとに一つの主作戦と一つの補助作戦まで
- アーキテクチャの責務は3領域程度
- 監査対象は重要なものから示す
- プロンプト全文は示さない
- AIツール名の比較を主題にしない
- デバッグでは、事実、仮説、次の確認を一度に一つずつ示す
- 顧客打ち合わせでは、未確定事項と確約事項を混ぜない
一つの工程について、次の内容だけを説明できればよい。
- 目的
- 作戦
- 許可した操作
- 禁止した操作
- 結果
- 次の判断
調査ではAIを読取専用にし、関連コードと不明点を整理させました。
決済と在庫への影響が判明したため、自律実装を止め、人間が状態遷移を決めました。
設計確定後の定型実装だけをAIへ任せ、納品前に二重実行と復旧を確認しました。
この説明で、工程分割、AI制御、結果確認、作戦変更を同時に示せる。
説明を三つのパスへ分ける。
- 工程
- 作戦
- 権限
- 結果
- 作戦変更
- 業務ルール
- 責務境界
- ドメインモデル
- アーキテクチャ
- セキュリティ
- 異常系
- 回帰
- 復旧
- 運用
AI制御は、アーキテクチャの代替ではない。
アーキテクチャは、AIへ与える作戦の代替ではない。
リリース保証は、コード生成時の簡易チェックの代替ではない。
- 標準ワークフロー
- 工程分割の考え方
- AI作戦の設定方法
- AIと人間の責任境界
- 代表的な作戦変更
- 未知の論点を調査へ変換した事例
- 最小再現やIssueなどの調査成果物
- 品質水準の決め方
- 人間の監査範囲
- 成果物
- 面接で深掘り可能な論点
- なぜその工程へ分けたか
- なぜその作戦を選んだか
- AIへ何を許可し、何を禁止したか
- どの結果を受けて作戦を変えたか
- 何を事実として確認し、どの仮説を棄却したか
- AIの回答をどの一次情報で検証したか
- 何を人間または顧客へ戻したか
- なぜその設計を採用したか
- 何を採用しなかったか
- どこを人間が監査したか
- 何を自動検証へ任せたか
- どの異常系を確認したか
- 問題時にどう戻すか
- 別の課題でも同じ判断を再現できるか
職務経歴書には全プロンプトや詳細なコードを載せない。
工程と評価軸を共有し、詳細は面接で確認できる状態にする。
AI時代は、コードだけを成果物としない。
次をセットで示す。
- 工程分割表
- AI作戦記録
- 権限・禁止事項表
- 作戦変更履歴
- AI出力の採用・不採用記録
- 人間へ判断を戻した条件
- 調査ログ
- 事実・仮説・次の確認の一覧
- 環境情報と再現手順
- 最小再現コード
- 原因候補を棄却した記録
- 公式仕様、実装コード、既存Issueへの参照
- GitHub Issue
- 修正前後の比較
- 実装コード
- テストコード
- 受入条件
- 開発中の安全制約
- 納品前の検証記録
- 設計判断記録
- 採用しなかった案
- 顧客向け説明
- 開発者向け技術資料
- 運用手順
- ロールバック手順
成果物ごとに役割を分ける。
コードには How
テストには What
判断記録には Why
コメントや設計記録には Why not
作戦記録には How much autonomy
調査記録には Facts, Hypotheses, Next checks
最小再現には Reproducibility
Issueには Evidence and Expected behavior
検証記録には Evidence
運用手順には When and Who
| 項目 | 記録内容 |
|---|---|
| 工程 | 調査、試作、設計、実装、検証 |
| 目的 | この工程で確定させること |
| 主作戦 | AIへ優先させる方針 |
| 補助作戦 | 安全性や探索範囲を補う方針 |
| 権限 | 読取、編集、コマンド実行、外部接続 |
| 禁止事項 | DB変更、新規依存、本番操作など |
| 人間の判断 | 業務ルール、責務境界、受入条件 |
| AIの結果 | 調査結果、差分、テスト結果 |
| 切替条件 | 不明点、変更範囲拡大、検証不能など |
| 次の行動 | 続行、設計へ戻る、停止、追加調査 |
作戦記録は、AIの操作ログではない。
どの判断をAIへ渡し、どの判断を人間が引き取ったかを示す設計記録である。
| 項目 | 記録内容 |
|---|---|
| 現象 | 実際に起きていること |
| 期待値 | 本来起きるべきこと |
| 環境 | OS、バージョン、設定、依存関係 |
| 再現条件 | 現象を再現する最小の条件 |
| 観測済みの事実 | 実行結果やログで確認した内容 |
| 現在の仮説 | 原因または実現方法の候補 |
| 次の確認 | 一度に変更する一つの条件 |
| 棄却条件 | 仮説を捨てる結果 |
| 調査先 | 公式仕様、実装コード、テスト、既存Issue、DeepWikiなど |
| AIの役割 | 確認手順、比較条件、ログ候補、要約 |
| 人間の判断 | 仮説の採用、調査終了、修正方針、顧客への回答 |
| 成果物 | 最小再現、テスト、Issue、修正差分、検証記録 |
調査記録は、AIとの会話ログをそのまま保存するものではない。
どの事実から、どの仮説を維持または棄却し、次に何を確認したかを第三者が追跡できる形にする。
ChatGPT、Claude、Codexを利用できます。
何を任せ、どの工程で使い、何を人間が判断したかを追加する。
詳細なプロンプトを書いてAIを制御しました。
目的、権限、禁止事項、停止条件、結果、作戦変更を示す。
最初に要件を渡し、実装とテストをすべてAIへ任せました。
工程を分け、工程ごとに自律度を変えたことを示す。
AI生成コードは必ずすべてレビューします。
現実性がなく、監査資源の配分能力も示せない。
必ずDDDとクリーンアーキテクチャを採用します。
課題、規模、寿命、事故コストに応じた判断を示す。
AIがテストを生成し、すべて成功したので安全です。
テストの対象、異常系、権限、回帰、復旧、運用を分けて示す。
PurchaseFlowとEventSubscriberを使います。
先に業務上の意味を説明する。
注文処理と画面変更を分け、在庫や決済への影響を限定します。
AIで開発速度を10倍にしました。
前提、品質、監査、検証、運用が分からない。
未経験ですが、分からないことはAIに聞けば対応できます。
AIへの依存、根拠不足、顧客への誤約束に聞こえる。
次のように説明する。
未知の問題は、確認済みの事実、仮説、次の確認へ分けます。AIには調査工程の分割を支援させ、回答は実行結果、公式資料、実装コードで検証します。未確定の費用、納期、実現可能性は、調査前に確約しません。
- ビジネス課題から説明している
- 共通ワークフローを記載している
- 工程分割の考え方を示している
- AIと人間の役割を分けている
- 工程ごとのAI作戦を示している
- 代表的な作戦変更を示している
- 人間の監査範囲を示している
- 検証方法を示している
- 顧客・開発者・運用担当者への説明を示している
- 導入・撤退方法を示している
- 技術名だけの列挙になっていない
- 未知の論点を調査へ変換した事例を示している
- 最小再現、調査記録、Issueなどの成果物を示している
- 面接で深掘りできる論点を残している
- ツール名ではなく利用工程を示している
- AIの目的、権限、禁止事項を説明できる
- 作戦変更の条件を説明できる
- 一般向け・技術者向けに説明粒度を変えられる
- 業務上の意味を説明できる
- 人間が保持する判断を明確にしている
- 未知を事実、仮説、次の確認へ分けられる
- AI回答を一次情報で検証する方法を示している
- 成果物と検証方法を示している
- 開発工程を複数のステップへ分けている
- 各ステップの目的を説明できる
- 各ステップのAI作戦を説明できる
- AIへ許可した操作を説明できる
- 禁止した操作を説明できる
- 作戦を変更する条件を定義している
- 人間へ判断を戻す条件を定義している
- AIの結果を記録している
- 複数の作戦を組み合わせた事例がある
- 根拠不足のときに追加調査へ切り替える条件がある
- 現象と期待値を分けている
- 環境と再現条件を固定している
- 確認済みの事実と仮説を分けている
- 原因の断定より再現を優先している
- 一度に一つの条件だけを変更している
- 各確認で何が分かるか説明できる
- 仮説を棄却する条件を決めている
- AIの提案を実行結果または一次情報で確認している
- 公式資料、実装コード、既存Issueへ調査を切り替えられる
- 最小再現コードを作成している
- 修正前後を比較できる
- 第三者が追試できる記録を残している
- 顧客へ未確定事項を推測で約束していない
- 次回も利用できる調査手順を記録している
- 「作る」と「作り込む」を分けている
- DDDや責務境界を別工程として説明できる
- 開発中の最低限の安全制約を定義している
- 納品前の厳密な検証を定義している
- セキュリティ上の前提条件を後回しにしていない
- 異常系、復旧、撤退を確認している
- リリース判断を人間が保持している
- 最初は30秒から2分で全体を説明できる
- 工程・作戦・結果から説明している
- プロンプト全文を説明していない
- 技術詳細は質問されたら追加する
- 制約と優先順位を示している
- 作戦変更の理由を説明できる
- 採用しなかった案を説明できる
- 人間の監査範囲を説明できる
- AIと自動検証へ任せる範囲を説明できる
- 正常系だけでなく異常系を示している
- 撤退・復旧方法を説明できる
- 未経験分野への対応を知識量ではなく調査手順で説明できる
- バグ対応を事実、仮説、確認、成果物の順で説明できる
- 顧客から持ち帰る情報と確約しない事項を説明できる
- 異なるビジネス課題でも同じ型を再現できる
AI時代の職務経歴書と面接で重要なのは、生成AIを使えること自体ではない。
評価すべきなのは、次の能力である。
- ビジネス課題を技術課題へ変換する
- 制約と優先順位を決める
- 開発工程を適切なステップへ分ける
- 工程ごとにAIの作戦、権限、禁止事項を設定する
- AIの結果を観測する
- 未知を事実、仮説、次の確認へ分ける
- 再現、切り分け、最小再現によって未知の範囲を狭める
- AIの回答を実行結果または一次情報で検証する
- 続行、停止、追加調査、作戦変更、人間への差し戻しを判断する
- 品質水準を案件ごとに変える
- 「作る」「作り込む」「保証する」を分ける
- 責務境界を設計する
- 人間が監査すべき境界を特定する
- 検証と受入条件を定義する
- 相手に合わせて説明する
- 小さく導入し、問題時に撤退する
- 顧客との打ち合わせで未確定事項を識別し、調査可能な形で持ち帰る
- 判断、調査手順、作戦変更を次の案件へ再利用する
職務経歴書を工程説明の正典にする。
面接では、どの工程で、どの作戦を使い、どの結果を受けて、何を人間が判断したかを確認する。
AI時代のエンジニア面接は、候補者がすべてを知っているかを確認する場ではない。
分からない問題を、確認済みの事実、仮説、次の確認へ変換し、AIの提案を根拠で検証できるかを確認する場である。
限られた人間の判断と監査を、どの工程へ配分するかを確認する場でもある。
完成したコードだけでは、候補者の判断は見えない。
工程、作戦、結果、切替条件を示すことで、AIを使って仕事を前へ進める能力と、AIを止める能力の両方を説明できる。
さらに、調査、再現、切り分け、一次情報への移動、第三者が追試できる成果物を示すことで、未知の分野や原因不明のバグに対しても、着実に仕事を進める能力を説明できる。
AIが与える安心感は、必ず答えを知っていることではない。
分からない状態から、次に確認できる小さな作業を作れることである。