AI を前提にした開発で差がつくのは、道具の数ではなく作業への構えのほうです。この記事では、日々の作業で実際に効いた 5 つのスタンスと、その手前で詰まっていた 3 つの課題を、使っている仕組みとあわせて整理します。

---

効率化の施策が効かなかった3つの理由

効率化の話は、たいてい「どのツールを入れるか」から始まります。ただ、施策は「何に詰まっていたか」とセットでないと、そのまま真似しても効きません。道具が同じでも、詰まっている場所が違えば効き方が変わるためです。そこで先に、詰まっていたことを開示します。

• 環境構築が終わった新メンバーの業務が、そこから捗らない。 セットアップは完了しているのに、その先の速度が出ない。環境を用意した時点では、まだ何も解決していませんでした
• ツールを入れただけで、活用まで至っていない。 入れた人間だけが使えて、あとは眠っている状態です。これでは導入のコストが回収できません
• 全員が同じ認知で作業できていない。 同じものを見ているのに前提がずれる。3 つのなかでは、ここが一番きつい課題でした

自分自身の失敗もあります。タスクを並列に切り出さず直列で処理していたため、着手の重い仕事が後回しになり、後回しにするほど重くなる状態を自分で育てていました。この状態を gaipack では「呪いタスク」と呼んでいて、チームでの対処法はやれば数分、なぜか1ヶ月放置。gaipack の「呪いタスク」対処法で別途まとめています。

作業スタンスは5つ、道具の選抜基準は2つ

これから挙げるスタンスは、格好をつけて考えたものではなく、上の状態から抜けるために残ったものです。先に全体像を置きます。この 5 つは順番にも意味があって、自分の手元、AI への渡し方、直す場所、チーム、相手と、内側から外側へ広がっていきます。

スタンスが 5 つなら、道具の基準はもっと少なくて済みます。使っているのは「毎日触るか」と「時間短縮できるか」の 2 つだけです。基準を増やせば精度は上がりますが、3 つ以上あると選べなくなるので 2 つで止めました。週 1 回しか思い出さないものは結局忘れるため、頻度が低い道具はどれだけ高機能でも採用しません。打率ではなく出場試合数で選ぶ、という基準です。この 2 基準で選び直した結果どの構成が残ったかは、毎日触るか、時間が縮むか。AI 開発環境の一軍の選び方にまとめています。

速さと主導権は、自分で取りに行く

効率化のために最初に決めたのは、ツールではなく返す速さの基準でした。基準がないと「速くしよう」が気持ちの話で終わり、判断が揺れるためです。

基準は3つの数字で固定する

数字で固定しているのは次の 3 つです。

速さは目的ではなく制約として置く

速さを基準にすると、勝手に手段が変わります。1 日で終わらせる前提に立った瞬間、「全部自分でやる」という選択肢が消えるためです。調べ方も、渡し方も、道具の選び方も変わります。速さそのものを目的にしているのではなく、やり方を変えるための制約として置いています。

この制約に一番効いたのが並列化でした。冒頭で挙げた呪いタスクは、小さな仕事に切り出して同時に走らせられるようになった時点で溶けています。並列の実行は Claude Code の Subagents（小さな仕事を別の AI に切り出して同時に走らせる仕組み）に任せていて、レビューのような分けやすい仕事から順に切り出しました。

主導権は渡される前に取りに行く

速さの基準を置くと、次にぶつかるのは誰がボールを持つかです。ここで楽な方を選ぶと、後半で確実に困ります。楽な選択はたいてい「決めるのを後ろに送る」ことで、送った分は利息をつけて返ってくるからです。指示を待つのは楽ですが、決まったあとの手戻りを全部引き受けることになります。だから決まる前に入る、という順番にしています。

これは AI を使う前提だからこそ強く言える部分でもあります。試して砕けるコストが明らかに下がっているためです。以前なら 1 回作るのに数日かかったものが、いまは数十分で形になります。当たりに行かない技術的な理由は、もうほとんど残っていません。

PDCA の重みを実行と改善に寄せる

速さと主導権を基準にすると、PDCA の 4 つが同じ重さではなくなります。手元の感覚を文字にすると P DDDDDDDDDD C AAAAAAAAAA くらいの比率です。計画の精度で差がつくのではなく、実行と改善の回数で差がつくと考えているからです。

ここは誤解されやすいので補足すると、経験の価値が落ちるという話ではありません。落ちるのは、経験を積むのにかかる年数のほうです。同じ 1 年でも積める試行回数が変わるため、差はむしろ開きやすくなります。確認（C）の回数を減らせているのは、後述する機械のゲートが人の代わりに見ているからで、ノーチェックで出しているわけではありません。

WHY と WHAT を持ち、HOW は全部渡す

5 つのなかで一番再現性が高いのがこの線引きです。AI の活用で差がつくのは知識量ではなく、どこまで渡すかだからです。

人の手元には判断だけを残す

人は「なぜやるのか・何を得たいのか」を決め、「どうやるか」は AI が担う。この線引きは gaipack の AIDD スキームでも同じで、AIDD の正本は AI を「人間の判断をより正確で高速にするための支援ツール」と定義しています。開発の工程も切り分けずに渡します。要件・設計・デザイン・コーディング・テスト・ドキュメント・レビューは、どれも HOW の側にあるためです。

調べる、分析する、整理する、案を出すは渡し、「どれを選ぶか」だけを持つ。人の手元に残るのは判断です。

渡すものが悪いと結果も悪くなる

渡し方が雑なら、返ってくるものも雑になります。AIDD スキームが実装の 3 原則で Input と Output の分離を掲げ、インプット品質が成果物品質を左右すると書いているのはこのためです。開発スピード 2 倍以上という効果も、インプット品質 80% 以上という条件付きで成立するものとして定義されています。手元でやっているのは次の 3 つです。

• 数値・前提・観点を渡していない依頼は出さない。 渡さなかった分は、結局こちらで作り直すことになります
• 画面のことは、画面で渡す。 Skitch で撮って矢印を 1 本入れ、そのまま渡します。文章で場所を説明するより速く、間違いも減ります
• 同じ注意を毎回口で言わない。 作法は CLAUDE.md（Claude Code が毎回読むプロジェクトの規約ファイル）に書いて固定し、指示から消します

今日面倒だった仕事を、その日のうちに消す

効率化で一番よく聞かれるのが「何から手を付けるか」です。ここでは道具ではなく、選び方の話をします。

一番嫌いな作業から手を付ける

多くの人が選ぶ場所を間違えるのがここです。好きな作業から自動化すると手は動きますが、すでに苦にしていない作業なので削れる痛みが小さく、効果が出ません。探すのは、毎週繰り返している作業のなかで最も面倒で、最もコストが高くて、最も嫌われているものです。この 3 つが重なる作業は、どの現場にもたいてい 1 つあり、全員がその存在を知って見て見ぬふりをしています。

3 つ目の「嫌われている」が効きます。面倒で高コストで嫌われている作業は、自分の職場だけの事情ではないため、社内で解けた型が他のチームでもそのまま効きやすいからです。好きな作業を自動化しても、それは自分 1 人ぶんで終わります。

今日面倒だと感じた仕事から探す

とはいえ「最も面倒で、最もコストが高くて、最も嫌われている作業を探せ」と言われても身構えるだけで手は動きません。探し方はもっと雑でよくて、今日、面倒だと感じた仕事を 1 つ思い出して、それを消す。これだけです。毎日いちばん面倒だったものはたいてい同じ作業なので、記録していけば上位の候補は勝手に浮かび上がってきます。

ここで前の節の線引きが効いてきます。面倒だと気づけるのは人間だけで、イラッとした、手が止まった、また同じことをやっている、という感覚は AI には検知できません。一方で消す側は AI に渡せます。見つけるのが人、消すのが仕組みという役割分担です。

同じ指示を3回出したら仕組みに落とす

落とし穴が 1 つあります。面倒な作業を AI に投げると最初は感動しますが、それを毎日人の手で同じように指示しているなら、自動化ではなく手動の AI 操作です。作業の中身が置き換わっただけで、人が張り付いている状態は変わっていません。判定は回数で機械的に決めています。

• 同じ指示を 3 回出したら、その時点で仕組みに落とす。 3 回出したものは来週も出すため、繰り返した事実を合図にします
• 指示は頭の中ではなくファイルに置く。 ファイルに置いた時点で、他の人にも渡せる状態になります
• 起動も人がやらない。 決まったタイミングで勝手に走る形にし、人がやるのは出てきた結果の判断だけにします

個人技にしない。環境・手順・言葉を配る

ここからチームの話になります。自分だけ速いのは効率化ではなく属人化だからです。配っているのは環境・手順・言葉の 3 つで、環境は Devcontainer と mise、手順はスキルで配っています。ここでは一番難しかった「言葉」を取り上げます。

用語は人の記憶に頼らずそろえる

冒頭で挙げた「全員が同じ認知で作業できていない」への答えがこれです。用語集を作るだけなら誰でもできますが、それだけだと必ず更新が止まります。そこで、人が思い出さなくても更新される形に寄せました。

使っているのは Claude Code の Hooks（AI の操作の前後に決めたコマンドを自動で走らせる仕組み）です。SessionStart で用語を読み込み、PostToolUse の Write|Edit で検証と再生成を走らせています。辞書のメンテナンスを人の善意から外した、という言い方が近いです。あわせて codegraph（コードの定義と呼び出し関係をローカルのグラフに索引する道具）を MCP 経由で使い、影響範囲の調査を 1 回の問い合わせで返せるようにしています。手元のリポジトリでは、この用語グラフがノード 54・エッジ 137 まで自動で育っています。

人が相手にするのは AI 秘書だけにする

やめたのは、思いついた指示をその場のノリで投げて作らせるやり方です。AI の性能の問題ではなく、期待どおりに動くための土台がなかっただけでした。土台として置いているのは次の 2 つです。

• 窓口を 1 つに絞る。 Custom Agents は pm / dev / qa / security / design の 5 枚で、役割ごとの判断基準をファイルとして持たせています。人間が相手にするのは AI 秘書 1 人で、その先の振り分けは秘書に任せるため、人が覚えることが増えません
• 指摘は直して終わりにせず定義に書き戻す。 書き戻さないと毎回同じ会話をやり直すことになります。指摘を資産に変える、この往復を「ループエンジニアリング」と呼んでいます

自分の手元だけで速くなった状態は、チームで見ればまだ何も改善していません。配れない状態は、効率化されていないのと同じです。チーム全体へ AIDD の型を移して自走できる体制にする支援は、AIDD インハウスとしてサービス化しています。

相手の頭に、合わせにいく

最後のスタンスです。ここまでは自分の手元とチームの話でしたが、作業には必ず受け取る相手がいます。自分視点のまま進めると、最後に困るのは自分です。

見せる相手を作業の前に決める

作業に入る前に 1 行だけ決めているのがこれです。同じ調査をしても、相手が変われば出す形が変わるためです。中身は同じでも並べ方が変わります。

相手を決めずに自分視点で作ると、成果物はたいてい「やったことの一覧」になります。相手が見たいのは作業量ではないため、そこで話が噛み合わなくなります。しかも困るのは相手ではなく、その場で説明する自分です。これは相手への配慮というより、自分を守るための段取りです。

打ち合わせでは画面を奪う

もう 1 つやっているのが、オンラインの打ち合わせでの立ち回りです。聞いていて自分にドメイン知識があるならそのまま進めていいのですが、そうでない場面のほうが多く、分かったフリのまま持ち帰ると作ったものが丸ごとやり直しになります。そこで画面共有を奪って、その場で図にします。

1. 画面を奪う。 遠慮しない。ここで奪うのは、前に書いた主導権そのものです
2. その場で描く。 箱と矢印で十分で、清書はあとでいい。使っているのは tldraw / excalidraw / drawio のいずれかです
3. 指差して聞く。 「ここ、こういう理解で合ってますか」と聞く。曖昧な言葉は図の上でしか潰せません
4. その場で確定させる。 持ち帰らない。会議が終わった時点で認識のズレをゼロにします

目的は絵の綺麗さではなく、「これで合ってますか」と指させる状態を会議が終わる前に作ることです。図解ツールを 3 つ挙げているのは、道具の基準を「毎日触るもの」に置いた話と矛盾して見えますが、ここだけは相手がその場で開けるかを優先しているため、絞るより選択肢を持つ側に倒しています。

人が見る前に、機械で止める

5 つのスタンスの土台として置いている層が 1 つあります。AI は人が読み切れない量の成果物を一気に出すため、チェックを全部人の集中力に背負わせると必ず漏れます。人が見る前の段階に、機械で止める層が要ります。

仕込んでいるのは Lefthook の 3 段です。書式を強制する段、秘密情報を弾く段、更新履歴を生成する段の順に並んでいて、人が見るのは機械で止まるものが消えたあとです。

各段の役割は次のとおりです。commit-msg で記録の書式を機械的にそろえておくと、pre-push の git-cliff が更新履歴を自動生成できるようになるため、1 段目が最後に回収される形になっています。

• commit-msg: 記録の書式を機械でそろえる
• pre-commit: betterleaks と ast-grep で、API キーやパスワードの混入を提出前に弾く。ast-grep は構造で検索するため、自作ルールをリポジトリ全体に当てられます
• pre-push: git-cliff で、そろえた書式から更新履歴を自動生成する

betterleaks は「機能的に完成」を宣言した gitleaks の後継として原作者らが開発しているツールで、見つけた鍵がまだ有効かを HTTP で実際に検証します。実際に aws_access_key_id を混入させたコミットは、この段で止まって先に進めません。レビューで指摘すべきなのは設計であって、秘密情報の混入ではない、という切り分けです。

なお、Lefthook の parallel: true は公式にある機能ですが、手元の環境では逆に遅くなったためオフのままにしています。速そうに見える設定より実測を採る、という判断です。

まとめ

5 つのスタンスを振り返ります。

そのうえで、持ち帰るのは 1 つだけで十分です。今日から毎日触るものを 1 つだけ選ぶ。5 つ同時に始めると、たいてい全部やめることになります。

完璧を目指す必要もありません。60% でも先に出して反応を見たほうが、結果的に速く仕上がります。出したものにしか反応は返ってこないためです。gaipack では、こうしたスタンスと仕組みを社内で継続的に改善しながら、AI 駆動開発の型をお客様のチームへ移す支援も行っています。お気軽にご相談ください。