公開日

devlog #1:AI と壁打ちしながら設計を決める

ポートフォリオサイトの設計は、AI(Claude Code)に判断材料を集めさせて、決めるのは自分。決定メモの型と、3 件まとめて決めた話、AI の説明を公式ドキュメントで裏を取った話。

はじめに

いま作っているポートフォリオサイトは、作品とブログを載せる場。設計から CI/CD、運用までを自分で回す練習の場でもある。CI/CD に加えて監視を入れる、SLI/SLO を設計する、手を動かして学ぶ。この 3 つを最初に決めた。

作業は AI(主に Claude Code)と壁打ちしながら進めている。ただ、AI には決めさせない。選択肢と比較の材料を集めさせて、決めるのは自分。この記事も AI の出力をそのまま載せず、自分の言葉で書き直している。

決定メモの型

設計メモは、サイトのリポジトリとは別の非公開ノートに置いている。迷っている途中の検討はノートに、決まったものだけリポジトリの Issue や README、コードに移す。

決めないと先に進めない項目は、1 件 1 ファイルのメモにする。欄は 6 つ。

  • 何を決めるか(1 行)
  • 選択肢と、それぞれの良い点・悪い点
  • AI の推奨
  • 決めないと止まる作業
  • 後から変えにくいか
  • 状態(未決 → 決定。決めた日と理由)

いちばん効いているのは、AI の推奨と自分の決定を別の欄にしたこと。推奨どおりに決めたときも、決めたのは自分だと後から読んでわかる。

「後から変えにくいか」の欄もよく効く。変えやすいものはさっさと決める。時間をかけるのは変えにくいものだけでいい。

最初から Issue にしなかったのは、迷っている途中の検討を公開側に残したくなかったから。全部が設計判断というわけでもない。最初の 1 件は「開いている PR をどの順でマージするか」という一度きりの話で、ノートだけで片付いた。

お問い合わせは GitHub へ案内する

フォームは当面置かず、GitHub のプロフィールへ案内する。それまでは送信機能のないフォームを置いていたが、送れないフォームを出し続けても意味が無いだろ。メール送信(Amazon SES)は、独自ドメインを取ってからの課題として残してある。

ブログの記事はリポジトリで管理する

決めたのは 3 つ。最初は 3〜5 本の記事で始める。Markdown と Marp(スライド)の両方に対応する。記事は Git リポジトリを正本にして、デプロイのたびに DB へ upsert する。

管理画面から書く形にはしなかったので、記事は PR を通して入る。この記事もそう。記事を Lambda に同梱しなかった理由や、デプロイで記事が全部消える事故を防ぐ安全装置の話は、別の記事で。

構成は今のまま進める

結論は現状維持。Spring Boot を Lambda の SnapStart で動かし、DB は Aurora DSQL。この構成のまま進める。リファクタリングは、やることが決まったら別の課題に切り出す。この先作るミニゲームのランキング API も、この構成に載せる。

AI の説明を確かめ直した話

デプロイは GitHub Actions で、main に push するたびに Deploy ワークフローが走る。concurrency で同時実行は 1 つに絞り、cancel-in-progress: false で実行中のデプロイは止めない。CloudFormation のスタックを中途半端な状態で止めたくないから。

deploy.yml には、AI が書いた「後から来たものは待たせる」というコメントがある。これだと後続の実行が全部順番待ちになるように読める。実際に待てるのは 1 つだけ。GitHub のドキュメントにも、同じグループに待機中の実行があれば取り消されて新しい実行に置き換わると書いてある。残るのは、実行中の 1 つと最後に来た 1 つだけ。

これが効いてくるのが、Dependabot の PR をまとめて処理したとき。4 本の PR を 15 秒のうちに続けてマージした。間の Deploy は取り消され、走るのは実行中のものと最後のものだけ。各 Deploy はその時点の main を使うので、最後の 1 回で全部反映される。壊れはしない。ただ、どの PR のデプロイが成功したかは 1 本ずつ追えない。

こういうことがあったので、AI の説明はそのまま設計の根拠にしないと決めた。設定の意味みたいに「読めばわかりそう」なものほど、公式ドキュメントと実際の実行結果で確かめる。決定メモに AI の説明を書き写すときも、裏を取ったかどうかを分けて書いている。

今のところの付き合い方

今は 4 つを守っている。

  • 判断材料は AI に集めさせる。推奨は参考として別の欄に残す
  • 決めるのは自分。決めた日と理由を書く
  • AI の説明は、公式ドキュメントやコード、実際の実行結果で確かめてから使う
  • 迷った過程はノートに、決まったものはリポジトリに置く。devlog はノートから書き起こす

AI と壁打ちしたことは、記事や README にもちゃんと書く。どこまで AI に任せて、どこから自分で決めたのか、いつでも説明できるようにしておきたい。

次回は、Spring Boot を Lambda の SnapStart で動かし、Aurora DSQL につないだ話を書く予定。