元AI懐疑派の開発者が「仕事で使えるAI」にたどり着くまでの6ステップ

AIによるコーディング支援をめぐる議論は「便利」と「危険」の二択になりがちですが、ツールの使いどころを段階的に見つけていく方法もあります。HashiCorpの開発者であるMitchell Hashimoto氏は自身のブログで「AIに懐疑的だった自分がチャット中心の使い方からエージェントを前提にした運用へ移行していくまでの手順」を6つのステップに整理しました。
My AI Adoption Journey – Mitchell Hashimoto
https://mitchellh.com/writing/my-ai-adoption-journey
1:チャットAIでコーディングしようとするのをやめる
Hashimoto氏が最初に行なったのは「チャットAIで作業しようとするのをやめる」ことです。ChatGPTやGeminiのようなチャットAIは日常的には便利な一方で、コーディングにおいては学習済みの知識から「それっぽいコード」を出してくることが多く、間違いを直すために人間が何度も「違う」と言い続ける必要があるため非効率だとHashimoto氏は述べています。
チャットAIでコーディングをしようとする中でHashimoto氏が最初に「おおっ」と驚いた体験は、オープンソースのコードエディター「Zed」のコマンドパレットのスクリーンショットをGeminiに貼り付けてSwiftUIで再現させたところ、驚くほど良いコードが生成されたことだそうです。そのコードはHashimoto氏が開発するターミナル「Ghostty」のmacOS向けコマンドパレットに軽い修正だけで取り込まれたとのこと。
しかしこの成功体験を別のタスクに広げようとしたところ、既存のコードベースを前提にした改修においては結果が安定せず、コピー&ペーストで入出力を往復するだけでストレスが増えたとのこと。
そこでHashimoto氏はチャットの延長ではなくAI自身が道具を動かせる形にしないと伸び代が出にくいと気づき、「価値を出すにはAIエージェントが必要」だと結論づけました。

2:自分の仕事を同じ品質で再現させる練習をする
次にHashimoto氏が試したのがClaude Codeでしたが、「出力は手直しだらけ」「自分でやった方が早い」という感じで初期の印象は良くなかったそうです。
それでも諦めずにHashimoto氏が選んだのが「二度手間」の手法です。具体的にはまず人間が手作業でコーディングを行い、その後人間が作ったコードを見せない状態で、AIエージェントに人間が作ったコードと同等の品質と機能のものになるまでやり取りしてコーディングさせるという方法。
この二度手間な方法でAIの訓練を行ううちに分かったこととして、Hashimoto氏は「いきなり完成図を描かせずに、セッションを小さく具体的で実行可能なタスクに分割する」「あいまいな依頼をする時は計画と実行を分ける」「検証手段を渡すと自己修正が働きやすく後戻りが減る」という3つのポイントを挙げています。
Hashimoto氏はこの方法をとることによって「そもそもエージェントを使わない方が良い場面」を見分けられるようになり、時間の節約になった点も強調しています。
この段階でHashimoto氏は「AIエージェントに頼むのと自分でやるのとが同じくらいの速度」までは来たものの、まだAIに頼むことで速くなった実感は薄く、エージェントの面倒を見る感じが残っていたとのことです。

3:終業前の30分を「仕込み」の時間にする
Hashimoto氏の狙いは「自分が作業できない時間に少しでも前進させる」こと。Hashimoto氏は毎日最後の30分を確保し、1つ以上のエージェントを起動するようにしました。つまり、「勤務時間中にがんばる」のではなく「勤務時間外にAIに進めておいてもらう」という発想です。最初はこれもうまくいかずイライラしたそうですが、すぐに「AIが役に立つカテゴリ」が見つかったとのこと。Hashimoto氏が挙げたのは以下の3つです。
・深掘り調査
新しいツールやライブラリを採用するときは、公式ドキュメントを読むだけでなく「候補がいくつあるか」「ライセンスは商用利用に問題ないか」「開発が止まっていないか」「既知の欠点は何か」といった確認が必要になります。ただ、下調べには多くの検索と文章の読み込みが必要で、集中力が落ちやすい時間帯にやると時間が溶けがちです。
そこでHashimoto氏はAIエージェントに条件を渡して候補を洗い出させ、リンク付きで比較メモにまとめさせているそうです。たとえば「言語やライセンスの指定」「最終更新やコミット頻度などのメンテナンス状況」「長所・短所」「評判」といった観点で整理し、翌朝はそのメモを読んで「当たり候補」だけを自分で精査するという役割分担をしています。
・並列試行
実装前のアイデア段階では「できそうか」「罠があるか」「どの方向が良いか」を早めに掴むことが重要です。とはいえ、曖昧なアイデアを自分で一つずつ検証していくと、調べ物や小さな試作の繰り返しで時間がかかります。そこでHashimoto氏はAIエージェントに複数案を並行で試させ、翌朝に結果だけ受け取ることにしました。ここでの狙いは完璧な実装を作ることではなく「この案は無理筋」「ここが地雷」「代案はこれ」という当たりを付ける材料を集めることです。
・Issue/PRのトリアージ
GitHubで開発をしていると、バグ報告や要望が書き込まれる「Issue」や、コード変更の提案である「PR(Pull Request)」が次々に増えていきます。IssueやPRが増えるとまずは緊急度や種類で仕分ける「トリアージ」が必要になりますが、Hashimoto氏はこのトリアージをAIエージェントに任せてGitHub CLIで一覧取得や内容確認をさせた上で、分類結果を翌朝読むレポートにまとめさせています。
なお、Hashimoto氏はAUエージェントに夜通し自律的に試行錯誤させるほどの仕込みをしておらず、多くは30分以内に終わったとのこと。終業間際は疲れて生産性が落ちるため、そこを「仕込み」に回すことで翌朝の立ち上がりが良くなったそうです。

4:確実に成功するタスクだけをAIに頼み、通知は切る
この時点でHashimoto氏は「AIが得意・不得意」の輪郭がはっきりしてきたとし、前夜のトリアージ結果を見て「これはAIエージェントがほぼ解決できる」と判断したIssueを選んでバックグラウンドで1件ずつ走らせ、自分は別の作業を進めるという段階に進みます。
ここでHashimoto氏が重視しているのが「AIエージェントからの通知で作業を中断しないこと」です。実装中に突然呼び出されると、考えていた内容を思い出して元の作業に戻るまで時間がかかります。AIエージェントに「呼び出される」形にせず、区切りの良いタイミングでこちらから進捗を確認する運用方法をHashimoto氏は勧めています。
このAIと人間の並走は、「AIに頼るとスキルが向上しない」という懸念への対抗になるとHashimoto氏は述べています。AIに任せる作業ではスキル形成が薄くなる一方で自分が続ける作業では自然にスキルが伸びるため、トレードオフを調整できるという考え方です。
そしてこの段階でHashimoto氏は「もう元に戻れない」感覚になったとのこと。AIを使うことで効率が上がったという実感に加えて、好きな作業に集中でき、好きではない作業も最低限きちんと片付けられるのが良かったとHashimoto氏は述べています。

5:間違いを二度と起こさないためのハーネスを作る
AIエージェントを実用に近づけるには、うまくいかなかったときに人間が直して終わりにしないことが重要だとHashimoto氏は述べています。次に同じ依頼をしたとき同じミスを繰り返さないように環境側を整えていくという考え方をHashimoto氏は「ハーネスエンジニアリング」としています。
その方法は大きく2つに分かれます。
1つ目はAIエージェント向けのルールを育てる方法です。たとえば「このプロジェクトではこのコマンドを使う」「このAPIは使わない」「この手順で検証する」といったルールを「AGENTS.md」のようなファイルにルール集として書いておき、AIエージェントが間違ったコマンドを選んだり、存在しないAPIを探し回ったりしたら、その失敗を踏まえてルール集に追記するのだとHashimoto氏は説明しています。
2つ目は正しいかどうかをすばやく確かめる道具を用意する方法です。たとえば画面表示が崩れていないかを確認するために「スクリーンショットを自動で撮る」「関連するテストだけをすぐ回せるようにする」といった補助スクリプトを用意しておけば、AIエージェントが「直したつもりだけど本当に直っているか」を自分で確かめやすくなります。
なお、こうした道具の存在もルール集に書いてAIエージェントに教えておくと効果が高いとHashimoto氏は述べています。
Hashimoto氏は問題が起きたら「再発しないようにルールや道具を足す」、うまくいったら「正しく動いていると確認できる手段を増やす」という姿勢でハーネスを少しずつ育てている段階だとしています。
6:常にAIエージェントを動かす状態を目標にする
Hashimoto氏が掲げる目標は「常にAIエージェントを走らせること」ですが、バックグラウンドでAIエージェントを動かせているのは現状では通常の勤務日の10%〜20%程度で「まだ目標は目標」だとしています。
また、Hashimoto氏はAmpが提供するAIエージェントのDeepモードのような「遅いが丁寧」なモデルも併用しており、小さな変更でも30分以上かかる一方で結果が良い傾向があるとのこと。
ただし、手作業で進める仕事と「面倒を見る必要はあるがなぜか生産的なロボット友達」のバランスとして1つがちょうど良いとして、「複数のAIエージェントの同時稼働は今のところやりたくない」とHashimoto氏は述べています。

Hashimoto氏のこの投稿はソーシャル掲示板のHacker News上でも話題になっています。
My AI Adoption Journey | Hacker News
https://news.ycombinator.com/item?id=46903558
あるユーザーはこの投稿全体を「過剰な煽りがなく、バランスが良い」と評価した上で、2025年という年は懐疑派だった開発者もAIエージェントをワークフローに組み込み始めた転換点だったのではないかとして「まずは試してみるべき」とコメントしています。
Hashimoto氏が重視する「ハーネスエンジニアリング」の考え方を発展させ、AGENTS.mdのようなルール集を「成熟度」で捉える意見もあります。あるユーザーは「よくある失敗を潰す段階にとどまらず、失敗を予防接種のようにルール化して積み上げるとハーネスが免疫のように効いてくる」という趣旨の意見を投稿しています。
中には、「金額や、良い結果を得るまでにかかる時間的コストについて語られていない。便利に見える使い方ほどトータルでは高くつく可能性がある」と主張するコメントもありました。
・関連記事
「AIツールは貢献のために開示する必要がある」というテーマで大激論 - GIGAZINE
Claude CodeはGitHubの公開コミットの4%を占めており2026年末までに毎日のコミットの20%を超える見込み - GIGAZINE
AppleがXcodeとコーディングエージェントのClaude AgentやOpenAI Codexとの統合を発表、さらにMCPにも対応 - GIGAZINE
OpenAIがCodexのアプリ版を公開、複数エージェントを同時実行可能でOpenAIの開発者は「99.9%をCodex appでコーディングしている」とアピール - GIGAZINE
・関連コンテンツ
in AI, ソフトウェア, Posted by log1b_ok
You can read the machine translated English article Six steps from a former AI skeptic to cr….







