最初はよかった、でも途中で違和感があった
エンジニアとして働いていると、アウトカムの有無よりも数値が追いかけやすくなっていく場面が少なからずある。
その数値は、とあるツールで測られる。
コミット量やレビュー量や PR 数だ。当然、玉石混淆となるが、それは関係ない。数値を出していれば、とりあえず仕事をしている感は出る。
逆に、魂を込めた一コミットはそう簡単には可視化されない。
そんな感覚の中で、AIエージェントの精度が大きく向上していき、自分はもう藁にもすがる思いで手を伸ばした。
AIエージェントのおかげで圧倒的コーディング力を手にいれ、どんどんコードを量産する。
それはそうだ。目の前の数字を積みたいからだ。スピード優先で深い理解なんて後回しでいいのだ。
出来上がったものを理解すればいい。いや、そもそも理解しなくても AI が書いてくれるのだから、理解する必要もないのだ。こうして1機能の開発が完了した。
さて、ある時アラートがでて通知が来た。自分以外の誰かが先に調査をしてくれていた。
途中から自分にも声がかかる。
「なんでここ、こう実装したんですか？」
「……」
「この処理、どういう意図です？」
何も答えられなかった。それはそうだ。理解していないのだから。
デバッグなんてすぐにできるわけがない。
というかこのプロジェクトで自分がやっていたことはというと、エラーのたびに Claude と Cursor に投げまくって壁打ちをしていただけだ。猿でもできる。
そこで初めて気づく。あの時間はなんだったんだ。何を得たのだろうか。。。ただ深い絶望を感じながら、また数字を追う日々に戻るのである。
会社の評価軸を個人で変えるのは難しい。ただ、せめて個人で作っているアプリだけは、同じ轍を踏まないようにしようと思った。
方針を書くだけでは足りなかった
さて、先ほどの話を踏まえると、では何をすればちゃんとプロジェクトや
タスクに対して以前と同じように責任を持つことができるようになるのか
という話だ。
私が出した結論はやっぱり、自分で書くべきところ、ないしはアウトプットするところは残しておいた方が良いというのが暫定の結論である。
出来るだけ最小単位で AI を使って、コアの部分は自分が実装してレビューしてもらうのが良いのではないかと考えた。
コアの部分でこそ学びが大きいし、問題が起きるのもそこだろう。
そしてコアではない部分に関しては AI にほぼ任せてしまっても良いのではないかとも思っている。
この方針を CLAUDE.md にそのまま書いた。これで大丈夫だろうと思っていた。
ところが、実際のセッションに入ってみると、タスクごとに「これはコア？残り？」を Claude に文脈推定してもらう運用になっていた。
結果、私もぽちぽちするだけでほぼ書いてもらってしまっていた。
最初の反省をいかし理解することは頑張ったのでそこは褒めてあげたいところではある。
いかんいかん。本論に戻る。
結果、方針を書くだけでは、運用には落ちなかった。
台帳にしたら運用できるようになった
次に試したこととしては、各タスクの項目ごとに「コアかコアじゃないか」を事前に紐づけておくことだった。
個人開発ではあったが、Issue番号と紐づけて管理することで、煩わしい運用を回避し、自分がコードを書くところと AI に手伝ってもらうところの責務を分担できるようにした。
具体的には以下の手順になる。
- docs/learning-goals.md というチェックリストを作った
- 項目ごとに「🟥 コア（自分が書く）／🟦 残り（AI が書く）／🟨 混在」をタグ付け
- 各項目に対応マイルストーンと Issue 番号を紐づけ
これ以降、新しいタスクに入るとき、Claude はまず台帳を参照して「これは 🟥なのでユーザー側で書いてください」と先に確認するようになった。おかげで、自分もタスクごとに迷わなくなった
一応例を提示する。
docs/learning-goals.md の冒頭にはタグの凡例を置いている。
| タグ | 意味 |
|---|---|
| 🟥 コア | あなた自身が書く。Claude は設計観点の事前共有・完成後のレビュー・詰まったときのヒントのみ |
| 🟦 残り | Claude が書く。実装前に「何を書くか・なぜそうするか」を解説してからユーザー承認で実行 |
| 🟨 混在 | 設計・SQL・重要ロジックはコア、周辺の UI / 配線は残り |
その上で、実際の項目はこんな感じで並ぶ。
RLS（Row Level Security）の設計思想 🟥
RLS（Row Level Security）は、ざっくり言うと DB 側で権限を決める仕組みのことだが、この記事とは関係ないので説明しない
| 項目 | 扱い | 習得 |
|---|---|---|
| 「アプリ層で権限チェック」ではなく「DB 層で権限を強制」する発想の転換を言語化できる | 🟥 コア | [ ] |
| RLS ポリシーを自分で SQL で書ける | 🟥 コア | [ ] |
| 「閲覧は public、投稿は認証ユーザー限定」を SQL で表現できる | 🟥 コア | [ ] |
少しは具体的なイメージが伝わっていたら嬉しく思う。
三層構造で忘れない事を仕組みにした
もう一段だけ仕組みを足した。書く場所を三つに分けた。
-
CLAUDE.md
プロジェクトを開いたときに Claudeが最初に読みにくるファイル。ここには一番上のルールだけを書く。「コアか残りかの判断は learning-goals.md を見てから決めること」と書いておけば、毎回自分で思い出さなくても、Claude の方から先に参照してくれる。 -
docs/learning-goals.md
各タスクを項目レベルで書き出し、それぞれ 🟥 か 🟦 か 🟨 かを割り当てている。Issue 番号とマイルストーンも紐づいているので、作業に入るときは「今からやるのはこの項目」と指差しで確認できる。チェックボックスもつけたので、終わったものは埋めていける。 -
Claude Codeのメモリ機能
同じ運用ルールを別の形で登録しておいた。メモリに書いたものは、新しいチャットを開き直しても残っている。CLAUDE.mdを読み落とされたとしても、メモリに書いてあるので同じ運用に戻ってくる。要するに二重化しておいたのだ。
方針、台帳、メモリ。書く場所の役割がそれぞれ違うので、どれか一つに全部詰め込むと読むのも書くのも面倒になる。分けてしまえば、一つのファイルには一つのことだけ書かれている状態になる。
結局、何が変わったか
AIをパートナーとして受け入れる準備ができた。
- AI に任せる／自分で書くを毎回迷わなくなった
- AI にコード書かせて、自分は設計だけやるは、自分に一番収穫がない選択肢だとわかった(そもそもこんな状態だと、設計以前の話なのだが)
- 逆にUI の定型まで全部自分で書いても、時間を浪費するだけで学びが薄い
大感想ポエム
最近、AI の使い方について大々的に取り上げられる極端な話をよく耳にする。全部が嘘とは言わないが、半分くらいは view稼ぎやアルゴリズムの影響もありそうだなと思って眺めている。
結局、この恩恵を一番受けているのは、今までの経験値から感覚的に AIの実装を理解できるシニアやベテランなのではないか、という気がしている。自分がその域に届くかはわからない。
ただ、AIが出してきた実装を見た瞬間に「想定と違う」「想定通り、OK」と判断できるようにはなりたい。
そのためにも、プライベートでは学びながら最小単位で AIを使い、プログラムや設計の部分を自分の血肉に変えていく努力が必要だと感じている。