こんにちは、アンドドットの高根沢です。
エンジニアとして AI を本格的に使い始めて、早くも3年が経ちました。これまで色々なツールを試してきましたが、今メインで使っているのは Claude Code です。
またClaude Code を使う中で、自分の仕事の中身が3段階で変わってきた感覚があります。同じツールを使っていても、使い方そのものが変わっていく。
本記事ではその「AI活用の3段階」を、実際に何が起きたか・どこで詰まったかを含めて整理していこうと思います。
AI 活用が「なんとなく速くなった」で止まっている人にとって、自分の現在地と次の打ち手が見えるような内容になれば幸いです。
前提：段階は「人」ではなく「業務」につく
3段階といってもこの段階は線形に進むものではありません。「自分は2段階目だ」と一人称で語れるものではなく、業務の性質ごとに今いる段階が違うものだと思うのが良いです。
新規実装では2段階目でも、繰り返し業務では3段階目に到達できますし、その逆もあります。
だから問うべきは「自分は何段階目か」ではなく、「この業務は何段階目か」です。業務単位で現在地を言語化できると、次にどこを引き上げるかが見えます。
段階は人ではなく業務につく。同じエンジニアでも、業務ごとに今いる段階は違う
第1段階：対話しながら一緒に書く
最初のAIとの関わり方は、Claude Code とチャットしながら 小さな粒度のタスクを対話的に進めるスタイルでした。
たとえばリスト画面のローディング状態を改善したい時、こんな指示を出します。
「このフックのローディング表示を skeleton に変えてほしい。shadcn の
<Skeleton />使って、カードと同じ高さで3行分」
Claude Code が差分を出してくる → 確認しながら「ここのマージン詰めて」「タイトルのスケルトンは幅 60% にして」「同じパターンを他のリスト系フックにも適用して」と続けていく。
1回の指示は小さく、対話の中でコードの形を整えていく感覚です。1機能をまるごと任せるのではなく、普通に実装はさせるが粒度が小さい。実装の主体は Claude Code ですが、何をどこまで変えるか・次にどこを直すかは人間が握り続けています。
指示は小さく、対話の中で形を整えていく。差分の要点を Claude 側がまとめてくれるので、次の指示にすぐ移れる
この段階で生産性が上がる実感は強いです。タイピング量が減り、定型コード（ループ、エラーハンドリング、API レスポンスのマッピング等）を書く時間がほぼゼロになります。
ただし、設計判断と意思決定はすべて握ったままです。Claude Code は手を貸してくれているだけで、何を変えるか・どう設計するか・どこから手をつけるかは全部人間が決めている。
「AIで生産性が上がった」と最初に実感する段階で、多くのエンジニアがここで止まっています。理由は単純で、これだけでも十分速くなるからです。
第2段階：単体タスクをまるごと任せる
ある日、もっと粒度の大きい指示を出してみました。
「マルチテナント SaaS の AI チャット機能に、過去5件の会話履歴をプロンプトに含めるロジックを追加して。Prisma の
ChatMessageモデルからtenantIdでスコープして取得、ユニットテストも書いて、PR まで作って。チケット元のNotionページはhttps://notion.so/xxxx です。」
要件の解釈、対象ファイルの特定、実装、テスト、コミット、PR 作成。1段階目では自分が逐次やっていた工程を、Claude Code に 丸ごと任せる。人間は出てきた PR を確認するだけです。
大粒度のタスクを投げると、Claude Code 側が「現状調査 → schema 編集 → 実装 → テスト追加」と自分でタスクを切ってから進む
最初に手を出した時の体感は、「実装作業を時間単位で外注できるようになった」でした。1段階目は手が速くなる感覚、2段階目はそもそも自分の手を動かさない感覚です。
「N+1 を直して PR まで」「テナント切り替えメニューに検索欄追加して PR まで」「このバリデーション全画面に伝播させて PR まで」のような、やることが明確で範囲が限定された仕事は、ほぼ Claude Code に任せられます。レビューだけでマージできる。
ただしこの段階にも限界があります。「毎回人間が指示を出す」工程が積み重なることです。仕事を任せるたびに、
- どのチケットをやるか選ぶ
- 関連情報を集める（Slack の議論、Notion の仕様）
- どのリポジトリのどこを触るかの大枠を伝える
- 完了後に状態を更新する（Notion / Slack）
を毎回やる。1回1回は数分でも、1日に20回30回と積み重なると 結局そこが新しいボトルネックになります。
「Claude Code に任せれば速い」は正しい。しかし「任せるための前後処理」が次の課題として立ち上がってくる。多くの人がここで頭打ちになります。
第3段階：ハーネスで業務全体を自動化
ある日、Notion で管理しているフィードバックチケットを処理しながら気づきました。
「これ、毎回同じ流れだな」と。
- Notion でチケットを開く
- 内容を読んで Claude Code に説明する
- 実装方針を相談する
- 書かせる
- レビューしてコミット
- PR を作って Notion に戻ってきて状態を更新する
この 1〜6 がまるごと自動化できるんじゃないか、という仮説が立ちました。
実際にやってみたのが、Claude Code の /loop と skills を使ったハーネス構築です。
ハーネスとは、Claude Codeを賢く動かすための設定ファイル群のことです。
| 設定 | 役割 | たとえるなら |
|---|---|---|
| CLAUDE.md | AIへのルールや前提知識 | 「仕事の引き継ぎ書」 |
| Skills | よく使う指示をまとめたもの | 「業務マニュアル」 |
| hooks | 特定のタイミングで自動実行される処理 | 「自動チェックリスト」 |
具体的には feedback-ticket.md という slash command を1つ書きました。中身はざっくりこういう流れです。
エージェントは Notion から優先度順にチケットを取り、Slack で過去の議論を確認し、実装可能なら実装→PR→Notion 更新までやる。情報不足なら Slack に自動でヒアリング投稿し、Notion 側にも記録を残します。
/loop で回し続けるので、自分が他の仕事をしている間にも開発が前に進みます。緑色のコントリビューショングラフが、自分が手を動かしていない時間も埋まっていきました。
直近1年で 20,259 コントリビューション。自分が手を動かしていない時間も、ハーネスが回し続けて緑が濃くなっていく
ここでは主役が完全に AI です。人間は環境設計者と意思決定者になります。何のツールにアクセスさせるか、どんな手順で動かすか、どこで人間に判断を仰ぐか。プロンプトを書くというより、業務システムを設計している感覚に近いです。
ハーネスエンジニアリングの定義
ここで言う「ハーネスエンジニアリング」について、先に定義しておきます。
AIエージェントが自律的に業務を回せる「枠組み（harness）」を設計する仕事。
単発のプロンプトではなく、ツール権限・ワークフロー・失敗時の安全網・外部システム連携（Notion / Slack / GitHub 等） を組み立て、エージェントの実行環境そのものを構築する。
ハーネスエンジニアリングでは、コードを書く対象がプロダクトのコードから「AIが働く環境のコード」に変わる、と言ってもいいかもしれません。
学び①： 段階2と段階3の境界条件
2段階目から3段階目に進む過程で、最大の学びがこれでした。
インプットが構造化されていないと、AIは情報不足のまま実装に進んで事故ります。
2段階目までは、人間が都度指示を出すので 情報整理の責任は人間にありました。指示を出す前に Notion を読み込み、不足があれば自分で確認に走る。曖昧さがあっても人間がフィルターとなって事故が起きることはありません。
ただ3段階目では人間が逐一見ていません。 情報判定の責任をエージェントに移す必要があり、そのため曖昧な仕様のまま「なんとなく解釈」して実装を進めてしまうと誤った前提で動くコードが出来上がります。
そこで 3段階目でのfeedback-ticket.md には、以下のようなガードレールを最初から組み込み、情報が揃っていない時には勝手に進めず、確認に回す仕組みにしました。
- チケットの仕様が曖昧なら静かにスキップしない。Slack に自動でヒアリング投稿する
- 同じ質問を二重に投げないよう、当日の親メッセージにスレッドで集約する
- Notion 側にも「ヒアリング送付済」と記録する
これの仕組みが実際に効果を出るようにするためには、もう一つNotion 側にしっかり仕様を書く文化が必要でした。
具体的には、As-Is / To-Be、影響範囲、決定済み事項などの情報です。これがNotion揃っていれば、エージェントは情報不足を判定できますが、揃っていなければ何が不足しているかすら判定できません。
3段階目を成立させるのは、インプットの構造化（Notion 側の運用）とガードレール（ハーネス側の判定）、この両輪です。
ハーネス自身が「次のアクションは何か」を判定して停止する。情報が揃わない時は勝手に進めず、人間の確認を待つ
学び②：段階によって「速くなる場所」が変わる
3段階で生産性が上がるのは間違いありません。ただし、速くなる場所は段階ごとにまったく違う。
段階によって速くなるのは別カテゴリ。1段階目はタイピング、2段階目はタスク処理、3段階目は業務全体のスループット
言い換えるとこんな感じです。
- 1段階目: 自分の手の速度が上がる(自分の作業時間内で、より多く書ける)
- 2段階目: 自分の手から仕事が離れる(自分が手を動かさなくても、実装が進む)
- 3段階目: 自分の時間と仕事が独立する(寝ている間も業務が進む)
「AIで生産性が上がった」という言葉は便利ですが、1段階目の効果と3段階目の効果はカテゴリが違います。自分の業務がどの効果を必要としているかで、投資すべき段階が変わるので、きちんと把握して活用をしていくことが大事になってきます。
たとえば「設計判断のスピード」を上げたいなら、どの段階に進んでも改善しません。
それは AI で解決する話ではなく、別の打ち手(ドメイン知識・組織設計・意思決定プロセス)の問題です。逆に「業務の総量を増やしたい」なら3段階目までいかないと頭打ちになります。
自己診断：あなたはどこにいる？
冒頭のポジションに戻ります。段階は「人」ではなく「業務」につきます。
そこでやってみてほしいのは、日常的にやっている業務を3つ挙げて、それぞれが何段階目か言語化することです。
高根沢の場合だと
- 新規プロダクトの設計 → 1段階目（議論しながら逐次書かせる）
- 機能実装 → 2段階目（大粒度のタスクを単発で投げる）
- フィードバック対応 → 3段階目（ハーネスが回している）
業務によって段階が異なることが普通です。
重要なのは、3段階目に到達できる業務を1つでも持っているかどうかです。
1つ持つと、他の業務も「これも3段階目にできるんじゃないか」という発想で見られるようになり、自然と視野が広がりやすい状態になります。
まとめ
3年間AIを使い続けて見えたのは、エンジニアの仕事が「コードを書くこと」から「AIが働ける環境を設計すること」に移っていく、という感覚です。
3段階目を経験すると、自分の手を動かして1機能作るより、システムが回り続ける仕組みを作るほうが面白くなる。
AIに何を任せるかを考えるフェーズは、もう終わりに近い。次は、AIが働ける環境をどう設計するかです。
あなたの業務のうち、どれを3段階目に引き上げられそうですか？ぜひ考えてみるきっかけになれば幸いです。
Discussion