2026年8月第4週：Codex がペアプロ相手から実装担当になってきた

今週は個人サイトの開発をかなり進めました。 サイト自体がある程度落ち着いてきた一方で、Codexとの開発の進め方も少し変わってきました。

便利になったと感じる反面、エンジニアとしてこの先どうなるんだろう、と考えることも増えています。

今週やったこと#

今週は個人サイトの開発を中心に進めました。

開発#

こうして並べてみると、今週はNotesの記事管理をGitHub Discussionsへ移したことを中心に、 その周辺の開発環境や表示をかなり整えていました。

記事#

記事は2本公開して、以前公開した記事を1本編集しました。

• CodexのAGENTS.override.mdとAGENTS.mdの読み込み仕様を調べた
• Codexのスキルを明示的に呼び出す
• GitHub Pagesの仕様と制限を調べた（編集）

うまくいったこと・ハマったこと#

Codexに書いてもらって、自分でレビューする#

最近は、コーディングをCodexに任せて、自分は出てきたコードをレビューする形で開発しています。 今のところ、このやり方でうまく進められています。

以前は、自分でコードを書いてCodexにレビューしてもらい、指摘されたところを直す、という使い方が中心でした。 レビュー内容がわからなかったり、納得できなかったりしたときは、自分が納得するまでCodexと壁打ちしていました。

最近は、そこから少しやり方が変わっています。 何を実装するかは今もCodexと壁打ちしながら考えています。 アイデアが出たらまず共有して、本当に必要なのかを一緒に考える。 やると決めたものはIssueにして、実装はCodexに任せることが増えました。

実装されたコードは自分で読んでレビューします。 納得できない書き方があれば修正を依頼するだけではなく、自分でサンプルを書いて「こっちの方がよくないか」と聞くこともあります。 そのときは自分の好みだけで判断しないように、客観的にどう思うか、一般的でモダンな書き方なのかも確認しています。

以前は自分が実装してCodexにレビューしてもらっていましたが、今はCodexが実装して自分がレビューする。 役割が逆になってきました。

こういう開発の仕方が、これからもっと普通になっていくのかもしれないと感じています。 自分もその変化に適応しなければ、と思う日々です。

ドキュメントの書き方も整理した#

個人開発で使うドキュメントの書き方も整理しました。

Codex的には長い文章でも問題なく読めるのだと思いますが、自分は長い文章を読むのがあまり得意ではありません。 必要なことが簡潔に書かれていて、ルールごとに整理されている方が理解しやすくて好きです。

たとえば、スタイル規約は以前こんな書き方をしていました。

- ページ・コンポーネント専用のスタイルは、対応する `.astro` ファイルの `<style lang="scss">` に置く。
- 複数ページで再利用する UI パターンのスタイルは `src/styles/components/` に置く。
- サイト全体に出力するスタイルは `src/styles/foundation/` に置く。

これを、ルールの考え方を先に書いてから具体的な配置を示す形に整理しました。

- 原則: スタイルは対象に近い場所に置く。
  - ページ・コンポーネント固有のスタイルは対応する `.astro` に置く。
  - 共通 UI は `src/styles/components/` に置く。
  - サイト全体の基盤スタイルは `src/styles/foundation/` に置く。

ほかのルールも同じように、原則、厳守、例外を使って、何を守るべきなのかがすぐわかる形に整理しています。 Codexに読ませるドキュメントでもありますが、自分が後から読み返したときにも理解しやすい形になりました。

CSSを直すだけだと思ったら、そうでもなかった#

Notesのテーブルをスマホなどの狭い画面でも見やすくするために、横スクロールできるようにしました。 最初はCSSを調整するだけで終わると思っていたのですが、実際にはそれだけではうまくいきませんでした。

最終的には、MarkdownをHTMLへ変換するときに、生成されたtableをスクロール用の要素で囲む処理を追加しました。 CSSだけを触るつもりがMarkdownの変換処理まで改修することになり、思っていたより大掛かりな修正になりました。

少し見た目を変えるだけのつもりが、実際にやってみると思ったより大掛かりになることってよくあるよな、と思いました。

GA4まわりの同意の扱いが思っていたより複雑だった#

GA4を導入する中で、アクセス解析とユーザーの同意についても改めて調べました。

自分が最後にこのあたりを触ったのは3年くらい前です。 当時はCookieやアクセス解析について確認するポップアップを出すサイトが増えていて、 「こういう対応をするのが一般的になったんだな」くらいの認識でした。

今回改めて調べてみると、ユーザーの同意状態に応じたデータ収集の扱いなど、 思っていたより細かくルールが決められていました。 そのため、単純にGA4を入れるだけではなく、 プライバシーポリシーや同意後に計測を開始する仕組みも含めて対応しました。

こういう専門外だとなかなか知る機会のないことも、 AIに相談すると教えてもらえるので、便利な世の中になったなと思います。

AIと開発するようになって思うこと#

今週一番考えていたのは、Codexとの関係が変わってきたことです。 先ほど書いたように、以前は自分が実装してCodexにレビューしてもらっていましたが、 今はCodexが実装して自分がレビューする形になりつつあります。

自分が会社の社長だとしたら、以前のAIは優秀な秘書みたいな存在でした。 調べてもらったり、相談したり、自分の仕事を手伝ってもらったりする。

今はそこから、仕事そのものを任せられる社員に近い感覚へ変わってきています。 仕事を渡すと実装して戻してくる。それを自分がレビューして、必要なら直してもらう。 「自分を補佐してくれる存在」から「仕事を任せられる存在」になってきた感覚があります。

便利になった一方で、ここまでできるようになると少し怖くもなります。 「このままAIが進化したら、エンジニアの需要ってどうなるんだろう」と考えることが増えました。

自分が今担当している領域についても、「これ、かなりの部分をAIに置き換えられるのでは？」と思うことがあります。 AIを使えば使うほど便利さを感じる一方で、自分の仕事がなくなる方向にも進んでいるように感じて、少し焦ります。

それでも開発は続けると思う#

そんなことを考えながら個人サイトを作っていたのですが、一つだけ変わらなそうなこともありました。 やっぱり開発すること自体は楽しいです。

仮に将来、AIによってエンジニアという仕事の需要が減ったとしても、自分は何かしら作っている気がします。 それに、AIは仕事を代わりにやってくれるだけの存在でもありません。

一人で開発していても、わからない技術があればすぐに聞けて、迷ったら壁打ちできて、そのまま一緒に実装まで進められる。 常に隣に、技術を教えてくれたり相談に乗ってくれたりする存在がいるような感覚です。

正直、AIと一緒に開発している今が、これまでで一番開発していて楽しいと感じています。 以前より負担も少なく開発を進められるようになって、自分にとってはかなりいい環境になりました。

一方で、仕事では最近あまり「自分が貢献できている」という感覚を持てていません。

企画や要件は自分から出したものではなく、要件を整理しても最終的に決めるのは自分ではありません。 実装もAIに任せることが増えて、自分がやっているのはレビューや意見を出すことが中心です。 そこからさらにチームでレビューされ、指摘を受けながらプロジェクトに合った形へ修正してリリースする。

もちろんチーム開発なのでそれでいいのですが、自分の実力でどこまでできているのかが見えにくく、 周りに助けてもらっている感覚の方が強くなることがあります。

その点、個人開発では、自分がどこまで理解して、判断できるようになったのかが見えやすいです。 わからなかったことがわかるようになったり、以前できなかったことができるようになったりと、自分の成長も実感しやすいです。

自分が個人開発を続けているのは、そうやって自分の成長を実感できるところも大きいのかもしれません。

来週やりたいこと#

Working Corgiは、この一週間でだいぶ整ってきました。 まだやりたいことはありますが、そろそろサイトばかり触る状態から離れて、 止まっていたcompanion-appの開発を再開したいです。

いきなり機能開発に戻るというより、まずはWorking Corgiを作る中で決めた開発ルールや、 使ってみて便利だったツールをcompanion-appにも持っていくところから始めるかもしれません。

ただ、Working Corgiで一度やったことをcompanion-appでも改めて整備するのは正直面倒です。 このあたりは、いつか個人開発のベースとして共有できる形にできたらいいなと思っています。

来週は久しぶりにcompanion-appを触れたらいいなと思っています。