コードは書ける。でも「コード以外」が終わらない ― エンジニアのAI活用プロンプト

なごみ

2026/02/28

コードを書く時間。実は、1日の半分もない。

設計ドキュメント、コードレビューのコメント、障害報告書、技術選定の説明、見積もりの根拠……。エンジニアの仕事の半分以上は「日本語を書くこと」だったりする。

AIにアーキテクチャの最終判断は任せられない。でも「ドキュメントの下書き」「エラーの原因調査の壁打ち」「非エンジニアへの説明文」なら、かなり使える。

コードまわり

バグの原因を一緒に考える

エラーメッセージをコピペして「これ何？」でいい。

以下のバグの原因を一緒に調査してほしい。

エラー内容:
[エラーメッセージを貼り付け]

関連コード:
[該当コードを貼り付け]

発生条件: [いつ/どういう操作で発生するか]
期待する動作: [本来どうなるべきか]
試したこと: [すでに確認したこと]

以下を出して:
1. 原因の仮説（可能性が高い順に3つ）
2. 各仮説の検証方法
3. 修正案
4. 同じバグを防ぐためのテストケース

コードレビューの壁打ち

PRを出す前に、自分でセルフレビュー。

以下のコードをレビューしてほしい。

[言語名]
---ここにコードを貼り付け---

観点:
- 可読性（他の人が読んで理解できるか）
- エッジケースの考慮
- パフォーマンス（明らかなボトルネックがないか）
- セキュリティ（入力値の検証、SQLi、XSSなど）
- テスタビリティ

出してほしいもの:
- 「ここは良い」ポイント
- 「ここは直したい」ポイント（理由と修正案つき）
- 「好みの問題だけど」レベルの提案（あれば）

テストコードのたたき台

テスト書くの面倒、でも書かないと後で痛い。

以下の関数/クラスのテストコードのたたき台を作ってほしい。

[言語名]
---ここにテスト対象のコードを貼り付け---

テストフレームワーク: [Jest/RSpec/pytest/JUnitなど]
テスト方針: [正常系中心/エッジケース重視/カバレッジ100%狙い]

以下を出して:
- テストケースの一覧（何をテストするか）
- 各テストのコード
- モック/スタブが必要な部分の提案
- 「これは手動で確認した方がいい」ケースがあれば

設計の整理

技術選定の比較表

「なぜA を選んだのか」を説明できるように。

以下の技術選定について、比較と判断材料を整理してほしい。

目的: [何を解決したいか]
候補:
  - A: [技術名]
  - B: [技術名]
  - C: [技術名]（あれば）
制約: [既存スタック/チームのスキル/予算/パフォーマンス要件]
重視する点: [学習コスト/エコシステム/パフォーマンス/コミュニティ]

以下を出して:
- 比較表（項目×候補のマトリクス）
- 各候補の「ここが強い/ここが弱い」
- 推奨案と根拠
- 上司やPMに説明するときの3行サマリー

注意: 最終判断はチームで。AIの出力は判断材料として使う。

設計ドキュメントの骨子

「設計書を書く」のが面倒な理由は、ゼロから書くから。

以下のシステム/機能の設計ドキュメントの骨子を作ってほしい。

対象: [機能名/システム名]
概要: [何をするものか、1〜2文で]
主なユースケース: [3つくらい]
技術スタック: [言語/FW/DB/インフラ]
制約: [パフォーマンス要件/セキュリティ要件/既存システムとの連携]

以下の構成で:
1. 概要と背景
2. ユースケース
3. アーキテクチャ概要（コンポーネント図をテキストで）
4. データモデル（主要なテーブル/エンティティ）
5. API設計（主要なエンドポイント）
6. 非機能要件への対応
7. 未決定事項/議論が必要な点

条件: 完璧な設計書じゃなくていい。「議論のたたき台」レベルで。

ドキュメント

障害報告書

障害対応は終わった。でも報告書がまだ。

以下の障害の報告書（ポストモーテム）を書いてほしい。

発生日時: [日時]
検知方法: [監視/ユーザー報告/デプロイ後]
影響範囲: [何人/どの機能/何分間]
事象: [何が起きたか]
原因: [わかった原因]
対応タイムライン: [時系列で対応内容]
暫定対応: [やったこと]
恒久対応: [予定]

以下の構成で:
1. サマリー（3行で全体像がわかるもの）
2. タイムライン
3. 根本原因分析（5 Whys形式）
4. 再発防止策（短期・中期・長期）
5. 学び

条件: 犯人探しではなく、仕組みの改善に焦点を当てる。

非エンジニアへの技術説明

「で、結局いつ直るんですか？」に答えるために。

以下の技術的な内容を、非エンジニア（PM/経営層/営業）にわかるように説明してほしい。

説明する内容: [技術的負債/マイクロサービス移行/セキュリティパッチ/パフォーマンス改善など]
相手: [PM/CTO/営業/クライアント]
伝えたい結論: [だから○○が必要/○○日かかる/○○のリスクがある]

以下を出して:
- たとえ話を使った説明（技術用語なし、3文以内）
- 「なぜそれが重要か」のビジネスインパクト
- 「何をどうするか」のアクション（具体的に）
- 想定される質問と回答 3つ

見積もりの説明

「なんでそんなにかかるの？」への答え。

以下の開発タスクの見積もりを整理してほしい。

タスク: [タスク名/機能名]
見積もり: [○人日/○時間]
内訳（ざっくり）:
  - 設計: [時間]
  - 実装: [時間]
  - テスト: [時間]
  - レビュー/修正: [時間]
  - その他: [時間]
説明相手: [PM/クライアント/経営層]

以下を出して:
- 見積もりの根拠（なぜこの工数か）
- 「短縮するならここを削る」の選択肢
- リスクバッファの考え方
- 相手が納得しやすい伝え方

自分の成長

技術のキャッチアップ

新しい技術、追いかけるのも仕事のうち。

以下の技術を効率よくキャッチアップしたい。壁打ち相手になってほしい。

学びたい技術: [技術名]
今の自分のレベル: [全く知らない/概要は知っている/少し触った/業務で使いたい]
使える時間: [週○時間]
目標: [概要を理解/プロトタイプを作る/業務に導入]

以下を出して:
- 学習ロードマップ（ステップ順）
- 各ステップで読むべきリソース（公式ドキュメント優先）
- 手を動かす課題（学んだことを試すタスク）
- 「ここまでできたら次に進んでいい」のチェックポイント

条件: チュートリアルを上からなぞるだけにならないように。