2026年6月14日。非エンジニア（ディレクター）の天野が、73ファイル・8,685行のコードをGitHubに投入しました。実装したのはOpenAI codex。会員登録、初回ヒアリング、日々の報告、週次レシピ、管理画面、DBマイグレーション、管理マニュアルまで、MVPとして必要なものは初回コミットですでに一通り揃っていました。
このプロジェクトには、開発当初から一つの検証テーマがありました。非エンジニア（ディレクター）がAIを使えば、サービスを本番リリースまで持っていけるのか。
単に画面をつくれるか、コードを書けるかではありません。レビュー、セキュリティ、DB変更、デプロイ、テスト、本番運用までを含めて、実際のサービス開発をどこまで担えるのか。そして、その過程でエンジニアの専門性はどこで必要になるのか。
一方、その日のうちにエンジニアの黒田は全コードのセキュリティレビューを開始しました。指摘は27項目。高リスク7件、中12件、低8件。持病、アレルギー、体重、産後授乳。このサービスが扱うのは要配慮個人情報です。AIで一気にMVPをつくることと、それを安全に本番で動かし続けることは同じではありません。
ここから55日間。天野はAIを使って、どこまで自分で開発工程を担えるのかを一つずつ広げていきました。黒田はその横で、専門的なレビュー、セキュリティ、インフラ、運用基盤、監査を担いながら、どこまでを天野＋AI側へ渡せるのかを見極めていきました。
55日後、天野は実装だけでなく、レビュー、DB変更、デプロイ、本番運用、バックアップ基盤の設計判断までを担うようになっていました。黒田の役割は、初期の実装やインフラ構築から、品質確認、ガードレール、監査へと移っていました。
プロジェクト概要
| サービス | 管理栄養士監修のレシピ提供と日々の報告をベースにしたダイエット指導サービス |
| 期間 | 2026-06-14 → 2026-08-07（55日間） |
| 初回コミット | 73ファイル・8,685行 |
| 記録時点 | 84コミット（天野76・黒田8）／31本のPR（天野27・黒田4）／セキュリティ指摘27項目／運用スタッフ3名 |
| アプリ | フレームワーク不使用PHP 59ファイル・11,635行／MySQL 8.4 20テーブル・マイグレーション16本 |
| インフラ | レンタルサーバー＋CloudFront × 2／Route53／Terraform |
| 外部連携 | STORES／LINE |
1｜最初の3日間 ── まず、AIでどこまでつくれるのか
最初の検証はシンプルでした。非エンジニア（ディレクター）がAIを使って、サービスの土台をどこまで形にできるのか。その答えは、初回コミットの時点ですでにかなり見えていました。73ファイル、8,685行。ユーザー画面、管理画面、DB、管理マニュアルまで一式が揃っています。
一方で、黒田は同日から全コードを確認しました。見るべきものは、機能が動くかだけではありません。要配慮個人情報を扱うサービスとして、本番に出せる状態かどうかでした。6月14日に起票したセキュリティレビューには、CSVインジェクション、スタッフセッション、HTTPS強制、要配慮情報の保持方針など27項目が並びました。
翌15日、黒田は是正PRを提出しました。ただし、天野側でもすでに同じ指摘への対応が進んでいました。黒田が問題を見つけ、黒田が全部直す形にはしませんでした。天野は指摘を自分のcodexへ戻し、自分で修正を進めました。
この3日間で、今回の検証の基本形ができました。天野＋AIがまず実装する。黒田が専門的な観点から問題を見つける。修正可能なものは、天野＋AI側へ戻す。「非エンジニアがどこまでできるか」を確かめる以上、エンジニアがすべて引き取ってしまえば検証になりません。最初から重要だったのは、できない部分を代わりにやることではなく、どこまでできるようにするかでした。
2｜MVPの次に、本番の壁が出てきた
MVPはできました。次の検証は、本番公開でした。ここから、アプリそのものよりも、インフラ、SSH、DNS、SSL、DB移行といった領域の比重が大きくなります。
6月18日、黒田がデプロイ環境を13の論点に分けて棚卸ししたところ、当初利用していたプランではSSHが使えず、平文FTPなどの制約もあることが分かりました。プランを変更し、6月26日にSSHが開通します。ところが、Windows環境から公開鍵を登録すると、PowerShellの処理によって鍵が改行化けしました。このような実環境固有の問題は、AIでコードを書くこととは別の経験が必要になります。
黒田が原因を特定し、解決しました。ただし、そのまま「黒田しかできない仕事」として残しませんでした。次回から天野自身がcodexに作業させられるよう、AIへそのまま渡せる形でセットアップ手順を残しました。
この時期のポイントは、エンジニアの関与が増えたことではありません。専門性が必要な領域でも、どこまでを仕組み化して天野＋AI側へ渡せるかを試していたことにあります。黒田が一度解決する。その知識を手順やルールに変える。次から天野＋AI側で扱える領域にする。この繰り返しで、本番公開に必要な範囲を少しずつ広げていきました。
3｜7月9日 ── 非エンジニア＋AIが、エンジニアのPRを止めた
7月9日の朝、予定していたSSL構成が使えないことが分かりました。無料SSLは、他社DNSで管理しているサブドメインには発行できません。黒田はその場で方針を変更しました。CloudFront＋ACM。ユーザー画面と管理画面でディストリビューションを分け、Origin Pathを分離し、オリジントークン認証も入れる。その日のうちにPRとして公開基盤を作り上げました。ここは、黒田の専門性が強く出た領域でした。
ところが午後、そのPRを天野が自分のcodexでレビューしました。そこで2件の高リスクな問題が見つかりました。既存DBでマイグレーションが誤って再実行される可能性。そして、途中で失敗した場合に安全に再開できないこと。
黒田は指摘を受け、マイグレーション処理を再設計しました。適用履歴をファイル・文番号単位で記録し、再実行防止、途中再開、既存DBガードを追加。さらにローカルMariaDBと本番MySQL 8.4の構文差も2件見つかり、修正しました。
その日の夜。本番DB作成、マイグレーション、スタッフ作成、実URLでE2Eログイン。サービスを本番へ出せるところまで到達しました。
この日は、今回の検証にとって大きな転換点でした。それまでは「AIで実装はできても、技術判断やレビューはエンジニア側」という線引きも考えられました。しかし、天野＋AIがエンジニア側の成果物まで検証し、実際に高リスクの問題を見つけた。非エンジニア＋AIが担える範囲が、実装からレビューへ広がった瞬間でした。
4｜そこから6日間 ── 「AIで実装できる」から「本番まで回せる」へ
公開基盤ができた翌日から、検証の焦点は一段進みました。非エンジニア＋AIで、実装だけではなく開発工程そのものをどこまで回せるか。
7月10日。天野が初めて自らマイグレーションを追加しました。PRを作る。マージする。本番でpullする。migrateを実行する。機能を確認する。ここまでを一人で完了しました。
翌11日からは、ブランチ名が agent/ に変わります。codexクラウドエージェントに実装させ、天野自身は仕様、レビュー、検証、マージ判断へ回りました。AIにコードを書かせることよりも、AIが作ったものを本番へ運ぶ工程を人間が管理することが中心になっていきました。
13日にはCSSのキャッシュ問題が発生しました。黒田はチェックリストを増やすのではなく、CloudFrontのキャッシュそのものを全パスで廃止しました。人の注意力に依存する部分を、仕組みで減らす。人が熟練していないから注意させるのではなく、そもそも失敗しにくい環境を作る。
7月13日から14日の2日間で、天野は8本のPRを出しました。15日には全機能の通しテストを行い、自分で週開始日のバグを見つけ、その日のうちに修正して本番反映まで終えました。
この時点で、最初の問いに対する答えはかなり具体的になっていました。仕様 → AI実装 → レビュー → DB変更 → デプロイ → テスト → 本番反映。ここまでは、非エンジニア（ディレクター）＋AIで回せる。
5｜エンジニアのコード変更がゼロになった12日間
7月16日から27日。次の検証は、より分かりやすいものでした。エンジニアがコードを書かなくても、開発は継続できるか。
この12日間、黒田のコード変更はゼロでした。一方、天野の開発は続きました。LINE登録フロー。STORES購入フロー向けの規約更新。モバイルの日付入力修正。その他の運用改善。さらに、クラウドagentでPHP lintができない問題についても、天野自身がローカル環境を使って補うようになりました。それまで黒田が埋めていた穴を、天野側の開発フローへ取り込んだ形です。
黒田の仕事は、読み取り専用のヘルスチェックへ移ります。7月16日には、残タスクとして記録されていた項目を確認したところ、そもそも該当UIが存在しないことも判明しました。記録をそのまま受け取るのではなく、コードと実装状況を確認し、現体制では不要と判断してissueをクローズしています。
6｜最後の宿題 ── 実装の先にある「設計判断」まで担えるか
7月29日。最後に残っていた大きなテーマは、要配慮個人情報の保持とバックアップでした。ここでは、単にAIへ実装を依頼できるかだけでは足りません。複数の技術的選択肢から、どれを採用するかを決める必要があります。
天野は、退会から365日後の匿名化を実装。さらにGitHub Actionsを使った毎日の暗号化バックアップを設計しました。当初はSSHを使う案がありましたが、天野はサーバー側の制約を実機で確認し、強制コマンド制限が期待どおりには機能しないことを突き止め、SSH案を自ら棄却しました。代わりに、公開鍵暗号化＋HTTPS API＋トークン認証を選んでいます。
ここまで来ると、検証の対象は「非エンジニアでもAIでコードを書けるか」ではなくなっていました。AIを使いながら、技術的な選択肢を理解し、実機で確かめ、設計判断までできるか。その範囲まで天野側に広がりました。
一方、組織課金設定など自分の権限を超える部分については、Draft PRのまま止めて黒田の確認を待ちました。何でも自分でやることがゴールではありません。どこまで自分で判断でき、どこから専門家や権限者へ渡すべきかを判断できることも、自走の一部でした。
7｜最終監査 ── 専門家の役割はどこに残るか
8月6日から7日にかけて、黒田が最終監査を行いました。直近のPRのセキュリティレビューは指摘ゼロ。一方、DBフォレンジックによって、7月30日に行われた本番テストデータのリセット操作を検出しました。前後に暗号化バックアップを取得していたものの、この操作だけがGitHub上に記録されていませんでした。
黒田の検出事実と、天野側の作業記録は時刻まで一致し、一往復で確認は完了しました。そして、一つルールが増えました。コード変更がなくても、破壊的な本番操作はGitHubに記録する。
さらに監査では、注文照合ロジックのデータ整合性バグも見つかりました。天野はその日のうちに、回帰テスト11項目付きの修正PRを提出しています。
ここで見えたのは、今回の検証のもう一つの答えでした。非エンジニア＋AIで開発と運用を回せるようになっても、専門家による監査や検証には役割が残る。重要なのは、エンジニアが毎回実装することではなく、どこに専門性を置けば、非エンジニア＋AIの開発を安全に広げられるかでした。
55日間の検証結果
■ 非エンジニア（ディレクター）＋AIが担った範囲
仕様策定 → AIへの実装指示 → コードレビュー → マイグレーション → デプロイ → テスト → 本番反映 → DB運用 → バックアップ運用 → 技術的な設計判断
最終的には、本番サービスの日常的な開発と運用までを天野＋AI側で回す状態になりました。
■ エンジニアが担った範囲
初期セキュリティレビュー → 公開基盤・インフラ → DB移行設計 → ガードレール整備 → 品質確認 → ヘルスチェック → 監査
非エンジニア＋AI側で扱える範囲が増えるにつれて、黒田の役割は日常的な実装から、専門性が必要な領域へ移りました。
この検証から見えたこと
1｜非エンジニア＋AIでも、本番リリースまでのかなり広い工程を担える
今回、AIが担ったのはコード生成だけでした。しかし、人間側が仕様、レビュー、検証、判断を持つことで、実装からデプロイ、運用までを一つの工程として回せました。
2｜専門性が必要な領域は、消えるのではなく場所が変わる
セキュリティ、インフラ、DB移行、権限、監査。本番サービスでは、経験や専門知識が必要な領域が残りました。一方、その専門知識を毎回エンジニアが直接実行する必要はありませんでした。手順、ツール、ルール、ガードレールへ変えることで、次回から非エンジニア＋AI側へ渡せる領域も多かったのです。
3｜AIに任せるほど、失敗しにくい仕組みが重要になる
キャッシュ問題は、注意喚起を増やすのではなくキャッシュをなくしました。マイグレーション問題は、運用でカバーするのではなくツールを再設計しました。記録漏れは、次から記録が残るルールに変えました。AIを使って開発速度を上げるほど、個人の注意力よりも、失敗しにくい開発基盤と運用設計が重要になります。
4｜エンジニアが仕事を抱え込まないことが、検証を成立させた
短期的には、黒田が自分で直した方が速い場面もありました。それでも、天野＋AI側で解決できる領域は可能な限りそちらへ戻しました。非エンジニア＋AIでどこまでできるかを試す以上、エンジニアが実装を引き取れば、その時点で検証が止まります。この55日間では、専門家が助けることと、専門家が代わりにやることを分けました。
5｜記録を残すことが、自走と監査の両方を支えた
84コミット。31本のPR。14本のissue。コードだけでなく、判断、検証、失敗、修正理由までGitHubへ集約しました。唯一GitHub外で行われた本番操作だけが、後日の確認を必要としました。開発を非エンジニア＋AIへ広げるほど、誰が何をしたかを追える記録の重要性も高くなります。
55日間で見えた、一つの開発体制
今回の検証では、非エンジニア（ディレクター）＋AIが、プロダクト開発と日常運用の実行主体になる。その周囲を、エンジニアがセキュリティ、インフラ、DB、開発基盤、ガードレール、監査といった専門性で支える。という形が成立しました。
55日前。非エンジニア（ディレクター）が8,685行のコードを持ってきて、エンジニアが27項目の問題を指摘した。55日後。その非エンジニア（ディレクター）は、AIを使って本番開発と運用を回し、エンジニアはその開発を監査していた。
最初に置いた問い、「非エンジニアがAIを使えば、本番リリースまで持っていけるのか」に対して、一つの答えが出ました。本番サービスの開発・運用まで、非エンジニア＋AIが担える範囲は想定以上に広い。同時に、その範囲を安全に広げるためには、専門家の知識を実装作業だけに使うのではなく、基盤、ルール、レビュー、監査へ変換していくことが重要でした。
本記録は、git履歴（84コミット）、GitHubの全PR（31本）・全issue（14本）とそのコメント、ローカル作業文書（セキュリティレビュー・デプロイ設計・引き継ぎ資料）、およびプロジェクトメモリから再構成したものです。日付はすべてJST。文中敬称略。
AIを活用したプロダクト開発体制のご相談は、下記よりお問い合わせください。