SEのためのAIネイティブ研究術 — 研究の作法を実務の武器にする

ここまでの全部（研究ループ・学位フェーズの思考・研究ノート・文献レビュー）を、大学院に行かずに、AI Agentを日常的に使うソフトウェアエンジニアの実務に落とし込む実践ガイド。上司の言う「研究ノート」を、明日から使える形にする。

0. 大前提：あなたは既に"研究"の8割をやっている

デバッグ・技術選定・性能改善・PoC — これらは全部、研究ループ（問い→先行研究→仮説→検証→考察→公開）そのもの。足りないのは**「意識的に・記録付きで・再現可能に」やることだけ。研究の作法とは、既にやっている思考に規律と証跡**を足す技術。

そしてAI Agent時代には、これがさらに重要になる。理由は3つ：

AIで試行回数が爆増する → 何を試したか記録しないと即座に迷子になる。
AIの出力は確率的で再現しにくい → プロンプト・条件・結果の記録が再現性の生命線。
AIに思考を委ねるほど自分の判断根拠が曖昧化 → 「なぜそう決めたか」の外部化が効く。

1. 研究ノートを「エンジニアリング・ジャーナル」として実装する

研究ノートの4機能（思考の外部化・証拠保全・再現性・自己フィードバック → 03研究ノート）を、SEの道具に対応させる。

研究の道具	SEでの実装	主目的
ラボノート（1エントリの型）	作業ジャーナル（日次のdevlog）	思考の外部化・自己フィードバック
実験ノート（手順と生データ）	実験追跡（MLflow/W&B、ベンチ結果、A/Bログ）	再現性
意思決定の記録	ADR (Architecture Decision Record)	証拠保全・意思決定の追跡
事前登録(preregistration)	変更前の「成功条件」宣言	後付け解釈(p-hacking)の防止
系統的文献レビュー	技術調査ノート（候補・基準・比較表）	再現可能な意思決定
ジャーナルクラブ	コードレビュー / 設計レビュー	批判による盲点潰し

1エントリのテンプレート（研究ノートの型をそのまま移植）

## 2026-07-05 / [タスク名: 例) 検索APIのレイテンシ改善]

### 目的・仮説
- 検索APIのp95が800ms。キャッシュ層追加でp95を300ms以下にできるはず。

### 背景・位置づけ
- 既存: 毎回DB全文検索。過去のADR-012でElasticsearch案は保留済み。
- このスプリントのゴール「検索体験改善」の一部。

### 方法・手順（再現可能な粒度で）
- Redis を前段に。TTL=60s。対象は人気クエリ上位20%。
- 計測: k6で1000rps、5分。環境: staging, commit abc123。

### 観察・生データ（解釈抜きで全部）
- p95: 800ms → 240ms。ヒット率 68%。
- ただしキャッシュミス時 p99 が 1200ms に悪化。

### 考察・解釈
- 仮説は概ね成立。ただしミス時の裾が想定外に重い（DB接続プール枯渇の疑い）。
- 「成功/失敗」でなく差分で見る: 目標達成だが新しい問題が露出。

### 次のアクション / 新しい問い
- [ ] ミス時のプール設定を検証（新しい問い: プールサイズが真の律速か？）
- [ ] AI Agentに接続プール周りの既存実装を調査させる

このテンプレを devlog/YYYY-MM-DD.md に置き、Gitで追記管理する。消さない・その場で・全部・位置づけを書くの作法（→ 03）はGitと相性が完璧。

2. AI Agent時代に"効く"研究ノートの書き方（ここが新しい）

AI Agentを日常的に使うあなた向けの、研究ノート×AIの実践。

(a) プロンプトと条件を"実験の手順"として記録する

AIの出力は再現しにくい。だから研究の「方法」欄と同じ粒度で残す：

使ったモデル（例: claude-opus-4-8）・主要プロンプト・与えたコンテキスト・温度等の条件。
→ 「なぜこの結果になったか」を後から追える。AIとのやり取りは"実験"であり、条件記録が再現性の鍵。

(b) AIに「観察」させ、人が「考察」する分業

文献レビューAIの分業（AI=網羅と要約、人=問いの定義と解釈 → 04文献レビュー）を実務でも徹底：

AIに任せる：既存コード調査、候補技術の列挙・要約、ログからの異常抽出（＝観察・網羅）。
自分が持つ：問いの定義、評価基準の設計、結果の解釈、最終判断（＝考察・意思決定）。
判断の根拠は必ず自分のノートに書く。 AIに委ねるほど、根拠の外部化が自分の思考を守る。

(c) 事前登録の作法で「都合の良い解釈」を防ぐ

AIは尤もらしい後付け説明を無限に生成できてしまう。だから検証の前に成功条件を書いておく：

「p95 < 300ms かつ p99が現状より悪化しないなら成功」と先に宣言。
実験後にAIと一緒に解釈するとき、この事前宣言が"願望による歪み"のアンカーになる（＝研究の事前登録／preregistration の実務版、→ 04ツール）。

3. フェーズ思考を"働き方の階段"として使う

学士→修士→博士の思考の進化（消費者→再現者→生産者 → 01）は、SEの成長段階にも、1つのタスクの中での思考の深さにも使える。

フェーズ思考	いつ発動するか	問いの立て方
学士的（消費者）	新技術の学習、既存パターンの適用	「これはどう動く？」
修士的（再現者）	技術選定、PoC、根拠ある実装	「この方法でこの課題は解けるか？」
博士的（生産者）	前例の無い課題、アーキテクチャ設計	「本当に解くべき問いは何か？誰も答えを持っていない」

難しいタスクに詰まったら「今、自分は消費者モードで解こうとしていないか？博士的に問いそのものを疑うべきでは？」と自問する。**問題発見（解く価値のある問いを見つける）**は博士が数年かけて鍛える最難関スキルで、SEの上流工程でそのまま効く。

4. 批判的読解を"技術調査の標準手順"にする

論文の批判的読解7ステップ（→ 04文献レビュー）は、OSS・RFC・技術記事の評価にそのまま使える。AI Agentに下読みさせつつ、以下を自分で判断：

これが解こうとしている問題は何か
どんな仮定・前提の上に立つか
既存との差分（gap）は何か
証拠（ベンチマーク・事例）は妥当か、再現可能か
データから自分ならどう解釈するか（作者の主張を鵜呑みにしない）
限界・適用範囲はどこか
自分の文脈にどう接続するか

→ この7項目をAI Agentへのプロンプトのチェックリストにすると、調査の質が安定する。

5. 明日から始める最小セット（3ステップ）

大掛かりにやらない。まず最小で回す。

devlog/ を作り、1日1エントリ書く（§1のテンプレ）。完璧を目指さず「目的・観察・考察・次」の4行でも可。
重要な技術判断は ADR に残す（docs/adr/NNNN-title.md）。「文脈・決定・理由・却下案・結果」を書く。§2(c)の事前宣言も添える。
AIとの"実験"は条件を記録する（モデル・主要プロンプト・結果）。再現とふりかえりのため。

3週間続けると、「思考の軌跡が資産になる」感覚が掴める。研究ノートの本当の価値（自己フィードバックと再現性）はここで初めて体感できる（研究者も"やってみて初めて分かる"と口を揃える → 03）。

6. やりすぎないための注意（YAGNI）

記録は手段であって目的でない。書くこと自体が仕事にならないよう、粒度は「未来の自分が再現・追跡できる最小限」に。
全部をADRにしない。後戻りが高くつく決定だけ残す。
ツールは増やしすぎない。2026年の潮流も「統合ワークフロー＞ツール寄せ集め」（→ 04ツール）。まずMarkdown＋Gitで十分。

まとめ：研究の作法がSEに効く一文

研究とは「不確実な問いを、証拠を積みながら、再現可能な形で解く汎用技術」であり、ソフトウェア開発はその一形態。 大学院に行かなくても、①研究ループを意識し、②研究ノート（思考の外部化＋証拠＋再現＋自己フィードバック）を書き、③AIには"網羅と要約"を任せ自分は"問いの定義と解釈"を持つ——この3つで、研究者が数年かけて身につける"型"の中核を実務で獲得できる。