こんにちは。本サイト最初のブログ記事はこのサイトをAIで作った話にします。
このサイト、全部AI（Claude Code）で実装しました。私は全くコードを書いていません。
どんなものを作るかをAIと壁打ちしながら決めて、AIが作ったものを評価して、イマイチなところを修正してもらう。その繰り返しでできあがりました。
この記事は、AIを使った開発そのものを自分なりに試行錯誤した仕組み化の話です。
AIで開発したい人に少しでも役立つ部分があれば嬉しいです。
なお、この記事自体もAIと壁打ちしながら作成しました。
（文章もドラフトはAIに作ってもらいましたが、結局は大幅にリライトしました）
サイトをAIで作った理由
元々このサイトは、フロントエンドの勉強と実益を兼ねてReactで自作していましたが、数年かけても完成しませんでした（経緯は後述）。
そんな中、2026年に個人事業を法人化することになり、そろそろサイトをちゃんとしたものにしたいという気持ちが強まっていました（法人化の話は別の記事に書いています）。
ちょうど、フリーランスで参画している案件（スクラム開発のPO業務）をAIで回すうちに、サイトもAIで作れるなと思い、試してみることにしました。
アーキテクチャなどの構成は、AIが扱いやすくトレンドも押さえたものを提案してもらい、Astro + Tailwind CSS + Cloudflare Workers になりました。
AIを使って作ろうとした背景には、こんな考えもありました。
- 今の時代、人間が手でコードを書く場面は今後ますます減っていくし、コードレビューもAIだけでやるのが普通になるだろう
- そうすると人間の仕事は「要求の定義」や「責任を引き受けること」になる（多分）から、ものづくりはAIに任せるのが良いのでは？
AIで開発することの速度
実際にAIに開発を任せてみると、その速度に驚きました。
最初のサイト
2021/12の個人事業開始に伴いHPが必要と考え、Hugo（SSG）で簡易なサイトを作成しました。所要期間は約2週間。
「とりあえずサイト公開」が目的だったのでこだわりもなく、大した内容はありませんでした。
Reactで自作
その後Reactを勉強したいと考え、勉強＋実益を狙って React+Storybook+各種ライブラリでサイトを作り始めました。
確かに勉強にはなったし、参画した案件でも役に立ちましたが、新しい良いLinterを知ったら入れ替える、といったことをやっていたので遅々として進まず。。
2025/07から2案件の掛け持ちで稼働が増え、全く進まなくなりました。
AIで作り直し
前述の通り、PO業務をAIで回す中で、AIを使ったサイト構築をやってみようと思い立ち実行。
イチから作り直して全ページ作成まで6週間です。
ネットの記事などでは、1日で作ったとか、バズりそうな記事がありますが、ぶっちゃけフルタイムで稼働しながらそんなことはできません。（家族との時間も大切にしたいし）
それでも数年完成しなかったものが数週間で形になったスピード感は「段違い」の経験でした。
AIに任せきりにはできない
ただ、AIを使って開発するとだいたい次のようなことで品質も低下し、何度もやり取りを繰り返すことになり、ストレスが溜まります。
- 過剰実装になりがち：このサイトとは別で経費精算アプリを作ろうとしてみたのですが、細かいエッジケースまで考慮した実装をし始め、コード量が激増しました。実装が複雑になることで不具合も増え、なかなか開発が進まなくなり進行を断念しました。
- セッションの品質低下：やり取りが長くなると目に見えて品質が落ちる。セッションの序盤でやり取りしたことを忘れることはよくあります。Opusを使っててもボロいものはボロいです。
- 確認しない：「動作確認が完了しました」と言うのに、「実際にプロダクトを動かして確認したか？」と聞くと「正直に言うとやっていません。今すぐやります」と答える。これは「定型文か」って思うほど頻繁に言われてゲンナリしました。CLAUDE.mdに打鍵で動作確認すると書いてるのになぜ確認しないのか。。
こういった問題を仕組みで改善しました。
今でも思うようにいかないことは頻繁にありますが、随時改善することで徐々に成功率は上がってきたと思います。
色々試してはやめて、、を繰り返した中で、比較的効果のあったものを紹介します。
1：タスクは極力小さくする
以前試したAIでの開発時に、やり取りが長くなるほど品質が目に見えて落ちる問題を何度も経験したため、AIに渡すタスクを極力小さくしました。
具体的には、PBI（プロダクトバックログアイテム）を小さく定義し、サクッと終わる程度のPBIをたくさん作りました。
1セッションでは1PBIだけ対応し、完了すると新規セッションで次のPBIに対応します。
最初にPBIの実装を指示したらあとは完了報告を受けて了承するのみの単純なタスクに分解しました。
2：設計メモと進捗一覧
PBIを作り始める前に、設計用の全体像をメモにまとめたのと、PBIを作りながら、進捗管理用の一覧を作りました。
- 設計メモ：何を、どんな順で、どんな方針で作るかを1文書にしました。大まかな方針、地図を作るイメージです。
- 進捗一覧：全タスクが「未着手 / 作業中 / 完了」のどの状況なのかを管理します。複数セッションで状況を共有する目的です。
要件定義の結果やプロジェクトの目的をドキュメントに明文化して、進捗管理表を作った、というようなことです。人間の開発プロジェクトと、同じようなことを行いました。
3：完了前のチェックリスト
AIから「完了です。〇〇も対応済みです」と報告あり→「完了にしたなら△△も確認したよね？」と聞く→「いえ、やっていません。今すぐやります」
これが日常茶飯事で発生してました。
その時詰めても、次のセッションだと当然のように繰り返すので、完了の前に必ず通す確認をルール化しました。
各タスクの条件に、こういうチェックを常設しています。
- [ ] 自動テストがすべて通る
- [ ] ローカルでPlaywrightを使って打鍵確認（PC + スマホ幅）
- [ ] Cloudflare Workersの公開前プレビューでPlaywrightを使って打鍵確認これを満たさないとタスク完了にできない、というルールなのですが、正直なところ徹底はできてないです。
自動テストはコミット時に機械的にチェックして弾けますが、打鍵確認はたまにやらない場合がある。
何かしらの理由でうまくいかない時に妥協するようなケースがあります。
何かしら言い訳をして完了扱いにしてしまうことは人間でもあるので、ある程度仕方ないかなと思いますが、これは今後の宿題ですね。
4：憶測の回答や人間に忖度した回答をさせない
このサイトでは「憶測で答えるな、必ず事実を確認してから答えろ」というルールをAIに課しています。また、下手に忖度した回答をされてもあまり役に立たないため、全体ルールはこんな調子で書いてます。
# CLAUDE.md（全体ルールの一部・要旨）
- 憶測で答えない。一次情報（ツール実行結果・ソース・公式 docs）を確認してから答える
- 私に忖度せず、フラットに評価して提案するただし、こういうルールを書いても憶測で回答したり、忖度したような回答をされることはあります。 そんな時はあらためて以下のような内容をプロンプトに追加します。 これはちょこちょこ発生するので、定型文のスニペットにしてホットキーで入力できるようにしています。
ユーザーに迎合や忖度せず、プロフェッショナルとしてフラットに評価や提案をしてください。会話が長いと、AIは指示を忘れる
Claudeの場合、Opusといった高性能モデルを使っていても、会話が長くなると品質は目に見えて落ちます。全体ルール（CLAUDE.md）の中身や、セッション序盤で決めたことを忘れ始めるのです。
AIに調べてもらうと、これには裏付けがありました。「Lost in the Middle」という研究で、言語モデルは文脈の最初と最後はよく拾うが、真ん中は忘れやすいという傾向が複数のモデルで確認されているようです。
Claude Codeの公式ドキュメントにも「文脈が埋まると性能が落ちて、以前の指示を忘れ始める」という趣旨の記述がありました。
対処は前述の通りで、タスクを小さくしてセッションを短く保つこと、効かせたい指示をその都度打ち直すことです。指示の打ち直しは、結果的に「大事な指示を文脈の最後に置き直す」ことになるので、この研究結果とも方向が合っていました。我流でやってきたことは、間違っていなかったようです。
自走しきれないのが目下の不満
今一番の不満は、AIが自分だけでタスクを処理しきれないことです。
安全のため、AIはMacのサンドボックス上で動かしています。変なものを壊される心配がない代わりに制限が強く、コマンド実行やファイル書き込みのたびに「やっていい？」と承認を求められて止まります。
承認待ちの都度タスクが止まるのも、自分自身の作業を止められるのも効率が悪く、他のことに集中もできないため、一度タスクを開始すると最後まで自走できるようにしたいところです。
最初は「AI専用の壊れてもいいPCを1台用意して全権限で動かす」案も考えましたが、AIに調べ直してもらうと筋が悪そう。
実機のOSや認証情報がそのまま晒されるので、隔離としてはむしろ弱いみたいです。
筋が良さそうなのは次の2つでした。
- サンドボックスは使ったまま、詰まるところだけ設定でピンポイントに通す
- 公式の設定例を元に作ったコンテナ（必要な通信以外を遮断する仕組み入り）の中で動かす
サンドボックスの設定を都度弱めていくのもなぁ。。という気がしたので、devcontainerを選び、サイト構築の途中で実際に導入しました。
おかげで手元のOSと認証情報を守りつつ自走させられるようになりました。導入の中身は、別の記事で書くつもりです。
やってみてどうだったか
率直な感想は以下のとおりです。
- 速度は段違い。数年動かなかったものが数週間で形になった。これに尽きます
- モチベーションが続く。コードを書くこと自体よりも、モノが出来上がっていく方が嬉しいタイプなので、出来上がるまでが速いAIとは相性が良いです
- コストはかかる。以前は下位プランで利用制限にすぐ当たって中断ばかりだったので、いまは上位プランに「時間を買っている」つもりで払っています
- モデルは躊躇せずに良いものを使う方が、手戻りが少なくてトータルでラクできそうです
ただし、モデル性能を上げると応答時間も長くなるため、使い分けも大事かもしれません
最後に責任を持つのは人間
AIで作っていても、出来上がったものの責任を引き受けるのは自分しかいません。中身をチェックするのも、ダメな所を直させるのも自分の仕事です。
実装をAIに任せても、要求を定義して、結果を評価して、「最後に責任を引き受けるのは人間」というところは、個人開発でも実務でも同じですね。
まとめ：これから試す人へ
AIに開発を任せるのは、私にとっては外せない選択肢になりました。ポイントは「任せきり」ではなく「仕組みに乗せる」こと。
- タスクを小さく刻む
- 設計メモと進捗一覧を文書で残す
- 完了の前に必ず確認させる
- 憶測と忖度をさせない
特に文書化は地味に効きます。AIは会話が長いと忘れるし、セッションを跨ぐと別人になるので、大事な文脈は人の頭の中ではなく「AIに読まれる場所」に置いておく。
そのうえで、このやり方には向き不向きがハッキリ出そうです。
- 向く人：AIの答えを評価して「それは違うのでは？」と見抜ける／イマイチな部分を都度直せる／コードを書くことより成果に満足を感じる
- 向かない人：コードを書くこと自体が何より楽しい／真偽を判断できずAIの言いなりになってしまう／コストをかけたくない
私は「向く」側だったかなと思います。
なお、AIの進歩は速くキャッチアップが大変なので、最近は使うAIをClaudeに絞りました。
置いていかれないように追いかけつつ、今後もAIでのものづくりを楽しんでいくつもりです。