$ cat blog/

$ cat blog/entry_002.md

AIとの共同開発 — 人間が設計し、AIがコードを書く新しい開発スタイル

Co-Developing with AI — A New Style Where Humans Design and AI Writes Code

AI와의 공동 개발 — 인간이 설계하고, AI가 코드를 쓰는 새로운 개발 스타일

2026-03-26 entry_002 ./ai-collab/

設計書がプロンプトになった日

現役時代、新しいシステムを開発するときは必ず設計書を書いた。画面遷移図、データフロー図、状態遷移図、テーブル定義書。仕様を明確にしてからコーディングに入る。これが自分の開発スタイルだった。

AIと開発を始めて気づいたのは、この「設計書を書く力」がそのまま「プロンプトを書く力」に変換できるということだった。

例えば、kitemir.jp のユーザー認証を設計するとき、自分はこんなふうにAIに伝えた。

【要件】
- PHPでユーザー認証システムを実装
- JWT（JSON Web Token）方式
- トークンはHTTP Onlyクッキーで管理（XSS対策）
- リフレッシュトークン対応（有効期限24時間 / 30日）
- パスワードはbcryptハッシュ

【テーブル設計】
users (
  id INT AUTO_INCREMENT PRIMARY KEY,
  email VARCHAR(255) UNIQUE NOT NULL,
  password_hash VARCHAR(255) NOT NULL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
)

【API設計】
POST /api/auth/register  → 新規登録
POST /api/auth/login     → ログイン（JWT発行）
POST /api/auth/logout    → ログアウト（クッキー削除）

これは設計書だ。同時に、これはプロンプトでもある。AIにとって、曖昧な指示より構造化された仕様のほうがずっと正確なコードを返してくれる。40年間書いてきた設計書の書き方が、そのままAIとのコミュニケーション手法になった。

プロンプトエンジニアリングとは、結局のところ「要件定義」だ。

役割分担 — 人間はアーキテクト、AIはコーダー

開発を重ねるうちに、自然と役割分担が定まっていった。

> ROLE ASSIGNMENT:
> Human = Architect + Reviewer + QA
> AI = Coder + Documentor + Debugger
> STATUS = In perfect sync

自分の担当はこうだ。全体のアーキテクチャを決める。データベースのスキーマを設計する。APIのエンドポイントを定義する。セキュリティ要件を指定する。そしてAIが出力したコードをレビューする。

AIの担当はこうだ。設計に基づいてコードを生成する。必要な関数やクラスを実装する。エラーハンドリングを追加する。コメントとドキュメントを付ける。

これは、かつてプロジェクトマネージャーとして若手エンジニアと仕事をしていたときと同じ構造だ。違うのは、AIは24時間いつでも対応してくれることと、指示に対して文句を言わないことくらいだ。

レビューは人間の仕事

AIが書くコードは、だいたい8割は正しい。残り2割に問題がある。型の不一致、エッジケースの考慮漏れ、セキュリティの穴。特にセキュリティについては、人間のレビューが欠かせない。

例えば、AIが生成した画像アップロード処理を見たとき、拡張子のチェックはあったが、MIMEタイプの検証がなかった。拡張子を偽装した悪意あるファイルが通ってしまう。これはインフラエンジニアとして数十年間培ってきたセキュリティ意識がなければ気づかないポイントだ。

// AIが最初に書いたコード（不十分）
$ext = pathinfo($file['name'], PATHINFO_EXTENSION);
if (!in_array($ext, ['jpg', 'png'])) {
    return Response::error('Invalid file type');
}

// レビュー後に追加した検証（必須）
$finfo = new finfo(FILEINFO_MIME_TYPE);
$mime = $finfo->file($file['tmp_name']);
if (!in_array($mime, ['image/jpeg', 'image/png', 'image/webp'])) {
    return Response::error('Invalid file type');
}

AIはパターンを知っている。だが、「何を疑うべきか」を知っているのは、長年の経験を持つ人間だ。

AIは完璧じゃない。人間も完璧じゃない。だが、二人合わせれば、かなりいい線を行く。

CLAUDE.md — AIへの引き継ぎ書

開発が進むにつれて、プロジェクトの「状態」をAIに効率よく伝える必要が出てきた。毎回ゼロから説明するのは非効率だ。

そこで作ったのが CLAUDE.md というファイルだ。プロジェクトの全容 — 技術スタック、ディレクトリ構成、API一覧、DB設計、コーディング規約、禁止事項 — をすべてまとめた「AIへの引き継ぎ書」。新しいセッションを開始するたびに、AIはこのファイルを読んで現在の状況を把握する。

いま、自分のプロジェクトには3つの CLAUDE.md がある。kitemir.jp、shop.kitemir.jp、asp.kitemir.jp。それぞれのプロジェクトの全情報がこの1ファイルに詰まっている。

> $ wc -l CLAUDE.md
> 487 CLAUDE.md
>
> // 487行の設計書。これがAIとの共通言語。

これは通信プロトコルの仕様書と同じだ。送信側（人間）と受信側（AI）の間で、データの形式と意味を合意する。曖昧さをなくし、誤解を防ぐ。結局、自分がやっていることは40年前と変わらない。プロトコルの相手がハードウェアからAIに変わっただけだ。

8つのプロダクトが生まれた

この開発スタイルで、4つのWebサービスと4つのiOSアプリをローンチした。

kitemir.jp（AIファッション診断＋バーチャル試着）。shop.kitemir.jp（アパレルEC「Maison Kite」）。asp.kitemir.jp（VTO-EC Suite B2B ASPサービス）。vto.kitemir.jp（このサイト）。そしてiOSアプリが4つ。すべて、設計は自分、実装はAI。

HTMLもCSSもPHPもJavaScriptも、1行も書けなかった男が、ここまで来た。

正確に言えば、「書けない」のは今も変わらない。白紙の画面に向かって、ゼロからコードを書くことはできない。だが、設計はできる。レビューはできる。どこにバグがあるか、なぜそのコードが危険か、見抜くことはできる。

それで十分だった。

$ git log --oneline --all | wc -l
    347

// 347コミット。
// すべて人間が設計し、AIが実装し、人間がレビューした。
// これが自分たちの開発スタイルだ。