ハクソク

世界を動かす技術を、日本語で。

私のAI導入の旅

109日前原文(mitchellh.com)

概要

  • AIツール導入の体験を段階ごとに解説
  • チャットボットからエージェント活用への移行
  • 自分の作業再現や効率化の工夫
  • エージェントによるタスク分担・自動化の実践
  • 現状の課題と今後の展望について整理

AIツール導入のリアルな変遷と活用法

  • AIツール導入 時は、非効率→十分→革新という 3段階 を経る体験
  • 新しいツール導入は 面倒 で、既存のワークフローに満足していると 抵抗感
  • それでも 幅広いスキル を持つために導入を決意
  • 本記事は AIツール活用 のリアルな体験と今後の挑戦を記録
  • AIに対する 過度な期待や誇張 ではなく、 現実的な視点 を重視

ステップ1：チャットボットから離れる

  • ChatGPTやGemini などの チャットボット での作業は 効率が悪い
  • コーディング用途では、 人間による修正 が頻発し、 手間と時間 がかかる
  • チャットUIは 最初のAI体験 として有用だが、 実務では限界
  • エージェント （LLMがファイル読み込み・実行・HTTPリクエストが可能なもの）を使う必要性
  • エージェント 活用で、AIの本当の価値を引き出すことが可能

ステップ2：自分の作業を再現する

  • Claude Code などエージェントを試すも、最初は 満足できない結果
  • 手動作業 と エージェント作業 を両方実施し、 違いと限界 を体感
  • 作業を 明確なタスク に分割し、 大きな一括依頼 は避ける
  • エージェントが 自己検証 できる仕組みを用意すると 精度向上
  • どの作業がエージェントに 向いているか を見極め、 効率的な利用 が鍵

ステップ3：終業時エージェント運用

  • 毎日終業前30分 でエージェントを 自動実行
  • 自分が作業できない時間帯に 効率化 を狙う
  • リサーチ や アイデア出し、 Issue/PRのトリアージ などに有効
  • 夜間ループ実行 はせず、 短時間で完了 するタスクに限定
  • 翌朝の ウォームスタート 効果で、作業効率アップを実感

ステップ4：得意タスクの外注化

  • エージェントが 得意なタスク を見極め、 完全自動化
  • 毎朝、前日の エージェントレポート から 簡単なタスク を抽出し、バックグラウンドで実行
  • 自分は別の作業 に集中し、 通知はオフ で 集中力維持
  • 人間が介入するタイミング を自分でコントロール
  • AIに任せる部分 と 自分で手を動かす部分 のバランスを重視

ステップ5：ハーネスエンジニアリング

  • エージェントの 誤動作 を検知したら、 再発防止策 （ハーネス）を構築
  • AGENTS.md などの プロンプト強化 で単純なミスを減少
  • 専用スクリプト や テストツール を整備し、エージェントの 自己検証力 を高める
  • 悪い挙動 があれば都度改善し、 良い挙動 も検証できる仕組みを意識
  • 継続的な改善 でエージェントの信頼性向上

ステップ6：常時エージェント稼働

  • 常にエージェントが稼働 している状態を目指す
  • Amp deep mode など、 時間はかかるが精度の高いモデル を活用
  • 複数エージェント運用 は未導入、今は 一体運用 が最適と判断
  • 自分の手作業とAIの自動化 の バランス を重視
  • 無意味な自動化ではなく、本当に役立つタスク のみをエージェントに委任

現在の課題と展望

  • 現状 はAIツール活用に 満足 しつつも、 さらなる効率化 を模索
  • AIの存続や流行 にはこだわらず、 ものづくりの楽しさ を追求
  • ツールとワークフローの継続的改善 が今後の課題
  • AIの進化スピード に合わせて、 柔軟な姿勢 で取り組み継続
  • 現実的な視点 でAIと向き合うエンジニアリング姿勢

Hackerたちの意見

他のフロントページに載ってる投稿より、ずっと実用的でパフォーマンス的じゃないね。いい記事だ。

└

最後に、懐疑的な人でもLLMツールが自分のワークフローでどんな役割を果たすかを試すためのステップバイステップガイドがあるよ。誇大広告や魔法みたいなことはなしで、「僕はOSを全部コーディングしたけど、君もできるよ！」みたいな感じじゃなくて。

セッションを明確で実行可能なタスクに分けよう。一度に「フクロウを描く」みたいなことをしようとしないで。これが一番のポイントだと思う。極端な例を挙げると、エージェントに「numbersという変数を使って合計を計算するforループを書いて」と言えば、うまくやってくれる。でも、その範囲が狭すぎて、LLMを使う意味があまりない。一方で、「犬用のFacebookアプリを作って」と言うと、アーキテクチャやコード、プロダクトについてたくさんの仮定をしてしまって、親に見せるためのクールなプロトタイプ以上のものを生み出す可能性はない。コードにおけるLLMの成功した採用は、この絶妙なバランスを見つけることだと思う。過度に具体的な指示は生産的に感じられないし、広すぎる指示だと作業をやり直すことが多くなっちゃう。

└

実際、AIツールを使う中で僕が本当に楽しんでいるのは、ツールが得意なことについての教育された直感を形成し、タスクをうまくフレーミングしてスコープを決めることで、より良い結果を得ることだ。これは、アーキテクチャからコードの単位や関数に至るまで、モジュール化のような他のクラシックなプログラミング活動に非常に似た認知的な感覚がある。物事をどうレイアウトしてチャンクするかを考えるのは、プログラミングの楽しさの一つで、エージェントのためにタスクを分けるときにその感覚が戻ってくる。

└

何度も、コーディングエージェントに「出力を表示して」と頼むと、「print (output)」みたいにファイルが更新されちゃうことがある。自然言語とコードの間でコンテキストを切り替えなくていいから、なんか楽に感じるのかもね。

└

逆に、エージェントに「犬用のFacebookみたいなアプリを作って」って言うと、アーキテクチャやコード、製品についてたくさんの仮定をしてしまって、親に見せるためのクールなプロトタイプ以上のものは作れないってことがあるよね。面白いことに、これがLovableを試したときの僕の体験だった。オンボーディングプロセスは、僕が作ろうとしているアプリの詳細を説明させることで、失敗するための準備をさせられているようなものでした。Claude Codeで少しずつ進める方が、ずっと成功してるよ。

└

実は、仕様を書くのが好きなんだよね。キャリアの大部分でコンサルティングの仕事の大きな部分を占めるほどに。だから、こうやってGen-AIと一緒に作業するのが楽しいのも納得。細かく分けて説明すればするほど、確認が楽になるし、30%も間違ってない結果が得られる可能性が高くなるんだ。

└

その通り。LLMは「コードインペインティング」が得意で、例えば「アウトラインや制約、ルールを教えてくれれば、空白を埋めるよ」って感じ。でも、突然新しい（堅牢な）機能を作るのは得意じゃないね。

└

最近では、モデルのリリースサイクルに合わせて、その“スイートスポット”が6〜8週間ごとに上昇してるね。

└

でも、範囲が狭すぎてLLMを使う意味があまりないんだよね。forの構文の例を探すためにコンテキストを切り替える手間が省けることが多い。初期のLLMコーディングでは、こういう使い方がほとんどだった。

これは僕の経験と一致してる、特に「フクロウを描くな」とハーネスエンジニアリングのアイデア。僕が直面していた失敗のパターンは「間違いを犯す」だけじゃなくて、ドリフトだった。ローカルでは妥当なことを言っているのに、リポジトリの実際の制約から徐々に離れていく。出力は自信満々に聞こえるから、現実（テスト、ランタイムの挙動、パフォーマンス、運用、UX）にぶつかるまで気づかない。僕にとってうまくいったのは、チャットを計画を形作る場所（トレードオフ、不変条件、失敗のパターン）として扱い、エージェントをその計画に対して狭く、レビュー可能な差分を行うものとして扱うことだった。人間の仕事はとても退屈なまま：実行して、検証して、実際に受け入れられるものを決める。それが僕にとっての「クリック」だった。ループが安定したら、ただの玩具じゃなくてレバーになった。いくつかのプロジェクトで実際の機能を出荷したよ（重いメディアプロジェクトのためのgitのようなツール、実際のユーザーとのチケット/決済フロー、ローカルファーストの系譜ツール、小さなCMS/出版パイプライン）。共通のテーマは同じ：小さな差分、迅速な検証、エージェントが気づかれずにドリフトしないようにハーネスをどんどん締めていくこと。

└

これはAIツールを使いこなしている人たちからの最も一般的な答えだけど、これが今までのソフトウェアの作り方とどう違うのか、ちょっと気になっちゃう。10年以上やってきたからね…。

最低限、エージェントはファイルを読み込み、プログラムを実行し、HTTPリクエストを行う能力を持っていなければならない。それはサイモン・ウィリソンの致命的なトライフェクタから一歩離れた非常に短いステップだ。

└

それは絶対に自分のマシンでは動かさないよ。

みんな同じような道を歩んでるのが面白いよね。今は複数のモデルを同時に動かしてるよ。コードベースの異なる部分でね。自分にとって退屈じゃないタスクだけに集中して、簡単なものは外注してレビューしてる。前のモデルの作業を確認するために別のモデルを使うことも多いし、自分でもやってる。git resetはまだよく使うけど、ツールをよく知ることで、その状態に至らない方法を見つけてる。自分たちの脳をオートコンプリートしてる！なんてクレイジーな時代なんだ。

これは本当に素晴らしいバランスの取れた、考え深い、ハイプのない投稿だね。2025年は本当に物事が変わった年で、多くの一流の開発者（以前はAIに懐疑的だった人たちも多い）が、ツールが実際に十分良くなってAIエージェントを自分のワークフローに取り入れられるようになった。AIコーディングツールが開発者の間でこんなに分極化したのは残念だね。理由は理解できるけど、もう少しスムーズな道があったらよかったのに。初期のLLM、例えばGPT-3は、見た目にはたくさんの可能性があるように見える程度にはコードができたから、投資を呼び込むためのハイプがたくさんあったし、当時の技術では実現不可能な約束もたくさんされた。これが多くのAI懐疑派（僕もその一人だった時期がある）や、開発者の間にシニシズムや疑念、抵抗を生んだんだ。でも、もし違った未来があったらどうなってたんだろう？変革的な新技術はこういう風に進化する運命にあるみたいだね。初期の航空機は非常に不安定で危険だったし、約束されていたほどの価値はなかったけど、進化と学びを重ねてダグラスDC-3が生まれ、最終的には747が登場した。もしまだAIツールが役に立つとは思っていない開発者なら、ミッチェルの投稿を読んで、彼がやったようにClaude Codeを試してみることをお勧めするよ。面倒なハイプやバイブコーディングのインフルエンサー、雑音を忘れて、ただ新しいツールを試すように扱ってみて。AIについての重要な会話はたくさんあるし、欠点も多いけど、適切な議論はツールとの密接な関わりから始まるんだ。

└

でも、AIに関する過剰な期待が問題だと思う。適度に使えば便利なツールだって分かるけど、管理者はスピードと納品の量を最優先にしてるから、彼らの期待に応えようとすると、この業界が崩壊しちゃうんじゃないかって心配してる。そうなったら、私たちユーザーや顧客は、メンテナンス不可能なバグだらけのソフトウェアの世界に直面することになるよ。

└

あなたの気持ち、すごく共感できる。10年後に何を転換点と考えるのか、ちょっと気になるね。スケーリングの限界やトレーニングデータが足りないっていう声が聞こえてきたと思ったら、ClaudeコードやSonnet 4.5、Opus 4.5が出てきて、それ以来誰も振り返ってないよね。

ただ、これは素晴らしくてとても現実的なまとめだと思ったので、伝えたかった。結果的にとても有益だったよ。ありがとう。こういう内容は、AIに賛成派も反対派も誇張に走っている現状の中で、さわやかな風を感じさせてくれるね。

エージェントに改善方法を教えなきゃいけないのが悲しいよね。常に自分が嫌だと思うことや改善点を伝えたり、明確化を求めたり、代替案をリクエストしたりしなきゃいけない。これが本当に面倒なんだ。まるで同じミスを何度も繰り返す子供みたい。だけど、少しずつエラーを減らすために自分で調整できるようにならないのかな？それができたら、あなたの考えを読み取れる究極のエージェントが誕生するかも！それは素晴らしいことだね。

└

これは心を読んでるわけじゃないよ。フィードバックを与えるのが楽しいのは、自分がエンジニアリングをコントロールしてるって実感できるから。新しい機能のリサーチにも使うのが好きだし。リサーチして、解決策を選んで、実装する。これがめっちゃ早く進むんだよね。

現実の世界での経験が豊富な人からのバランスの取れた意見を読むのは、すごくリフレッシュできるね。

AIを使って、システムや作業部品の特定の部分だけを変更する方法について、何かアイデアある？「この部分は80/100で完成してるから、ここだけは『意味のある』または『新しい貢献』をしてほしい」みたいな感じで…？