ハクソク

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

AIは簡単な部分をさらに簡単にし、難しい部分をさらに難しくする

106日前原文(blundergoat.com)

概要

  • 開発者体験 と システム思考 に関する課題と失敗の分析
  • AIワークフロー や 継続的改善、意思決定のための メンタルモデル の重要性
  • AI活用の落とし穴と、 責任あるコーディング の必要性
  • マネジメント と 持続可能な生産性 のバランス問題
  • AIの正しい使い方 と 人間の判断力 の両立が鍵

開発者体験とシステム思考の課題

  • エンジニア組織の サポート不足 が現場の課題
  • 品質を犠牲 にした開発では誇りを持てない現実
  • 現状の速度 を評価せず、スプリントの連続要求
  • 一度速く納品すると、その速度が 新たな基準 となる組織文化
  • エンジニアの疲弊 と品質低下の悪循環

AIワークフローの現実と落とし穴

  • 「AIは必ずしも 開発速度を上げない」という現場の実感
  • 従来は 自分で調査・検証 して結論を出していた
  • AIやGoogle に頼り過ぎると、 理解不足 や 責任感の欠如 を招く危険
  • AIが生成したコード は「他人のコード」と同じ扱い
  • コードを書くのは簡単だが、 調査・文脈理解・検証 が本質的な難易度

AI活用の実体験とリスク

  • プロトタイピングや個人プロジェクトでは AIのコーディング支援 が有効
  • 重要なプロダクトでは 1行ごとの責任 が求められる
  • AIにテスト追加を依頼したら、 ファイルの大部分が削除 される事例
  • AIとのやりとり やファイル復旧に余計な時間を消費、本末転倒
  • AIを調査ツールとして活用 し、即答に頼らないスキルの重要性

AI時代の開発者に必要なスキル

  • AI支援開発 で見落とされがちな「調査・検証」の重要性
  • AIが書いたコード を理解・レビューする難しさ
  • 文脈や背景知識 がないと、AIの出力を正しく評価できない
  • コードの 所有意識 と 責任ある運用 の必要性

マネジメントと持続可能な生産性

  • 無理な速度目標 が「AI出力のコピペ」や品質低下の温床
  • 6ヶ月後や深夜 に「AIが書いたから分からない」では通用しない現実
  • バーンアウト やバグ多発でAIによる生産性向上が帳消し
  • 「 AIはシニアのスキル、ジュニアの信頼」という考え方
  • AIは優秀な外部助っ人 だが、現場の文脈は理解していない

AIと人間の協働による最適なワークフロー

  • 責任あるコード管理 が不可欠
  • AI出力の 無批判な利用 は将来のトラブルの原因
  • 現場の文脈や背景 を開発者自身が補う必要性
  • AIは調査やアイデア出し でこそ真価を発揮
  • 人間の判断力とAIのスピード のバランスを取るワークフロー設計

AI活用の成功事例と教訓

  • プロダクションバグ調査で AIが初動調査を担当、人間が検証・意思決定
  • 原因特定と解決案提示 まで短時間で実現
  • AIの強みは調査・情報整理、最終判断は人間
  • 無理な残業や火消し を避ける持続可能な体制構築

組織・個人が意識すべきポイント

  • AIの「 10倍生産性」は、もともと調査が足りなかっただけの可能性
  • 自己調査・検証力 を鍛え直す必要性
  • AI活用の限界 と人間の役割分担の明確化
  • 継続的な改善 と 健全な開発文化 の醸成

Claude InsightsとAIツールの注意点

  • Claude Codeの/insightsコマンド はセッション分析レポートを自動生成
  • AIチャットボットやコーディングエージェント の「最初の回答」への過信は禁物
  • 調査・検証・文脈把握を怠らない開発姿勢

SEOと自己評価の視点

  • 「どうすれば上位表示できるか」より「 自分で自分を妨害していないか」の確認が重要
  • Googleに見つけやすく、理解しやすい構造 を意識するSEO戦略

まとめ AI時代の開発現場では、 AIの強みと限界を理解し、責任ある活用 が不可欠です。 システム思考 と 継続的な自己改善、そして 人間の判断力 が、真の生産性向上と健全な開発文化の鍵となります。

Hackerたちの意見

レトロエミュレーターとアセンブラをテスト付きで vibe コーディングしてみたんだけど、プロンプトは最小限で、すごくいい結果が出たよ（Gemini 3）。数年前に作ったアプリの難しいプロプライエタリ部分を vibe コーディングしようとしたけど、すごく技術的な領域で、例が全然なかった。GitHubにはエミュレーターが何千もあるけど、俺がやろうとしたことはゼロの例だった。今のところ、明らかな教訓は、簡単なものもあれば全然ダメなものもあるってこと。

└

俺はこれを「恥ずかしいほど簡単に解決できる問題」って呼んでる。GitHubにはエミュレーターの例がたくさんあるから、エミュレーターはLLMの潜在空間に存在してる。いつでも出してもらえるよ。恥ずかしいほど簡単に解決されてる。君がやろうとしたことの例は全くないけどね。

└

技術的にあまり人気のないニッチな分野で vibe コーディングを試みたけど、失敗した。その後、できるだけ問題を分解して、より明確な言葉で問題を提示したら、Geminiが数回の試行で動くコードを提供してくれた。これは一つの例だけど、問題をもっとシンプルに分解してみると、うまくいくかもしれない。ニッチな業界特有のフレームワークは、vibe コードモードで扱うのがちょっと難しい。でも、少し努力すれば、AIは自分でコードを書くよりも早いみたい。

うざい部分がちょっとマシになる気がする？それと、「エージェントと議論してファイルを回復するのにかかった時間は、自分でテストを書くのにかかる時間より長かった」っていうのも。俺の経験から言うと、LLMと議論するのは時間の無駄だし、ファイルを回復するのに時間を使うべきじゃない。小さな変更を一つずつやって、うまくいったらコミットして、ダメだったら変更を捨ててまたやり直せばいい。AIが万能だとは思わないけど、いつそれが適切なツールで、いつそうでないかを見極めることが大事だね。

└

でも、あいつが始めたんだよね…

└

バージョン管理や、過去のバージョンを簡単に戻せるIDEを使わないのは、ただの馬鹿げたことだよ。銃を持った子供と遊ぶつもりなら、防弾チョッキを着ておけ。

└

それが「ただ」簡単だとは思わないな。AIはユニットテストを生成するのが得意だけど、実際にはテストを通すためにこっそりハックしちゃうことも多いから、プログラムが何をするべきかの良い指標として使うことは少ないよ。

AIはただの大きな力の倍増器だと思う。もし君のコードベースが悪い基盤で、たくさんのハックで間違った方向に進んでいるなら、既存のスタイルを反映したコードを書くだけだよ… そうなると、まさにOPが言ってることになる。だけど、もし君のコードの基盤が良くて一貫性があってハックを許さないなら、AIはそのクリーンなスタイルを維持して、驚くほど良くなる。そうなると、プロンプトはほとんど重要じゃなくなる。コードの基盤が全てだよ。でも、多くの人がまだ悪い体験をしている理由もわかる。ほとんどのコードベースは悪いからね。動くけど（非常に厳しい制約の中で、特定の環境で）、メンテナンスが難しくて拡張も大変。ハックの上にハックが必要になる。新しい機能を追加するたびに、マイナーまたはメジャーなリファクタリングが必要で、全てが相互依存しているから、散らばったコード変更がどんどん増えていく（密結合、低い凝集性）。生産性は徐々に落ちて、以前は1人でできたことを100人のエンジニアがやらなきゃいけなくなる。これは新しい現象じゃない。ただ、AIのおかげで今はもっと明らかになっただけ。俺はこれを何年も言ってきたけど、実際に複雑なプロジェクトを自分で作ったエンジニアが少なすぎると思う。建築の設計にも似たようなことがあって、建物の基盤に制約される。普通の1階建ての家のために基盤を設計したら、建設プロセスの途中で20階建ての高層ビルを建てることに変更することはできない。でも、もし基盤が100階建ての高層ビルを支えられるほど良ければ、その上にほぼ何でも建てられる。俺の視点は、人々が vibe コーディングできるようにしたいなら、彼らに本当に強い基盤を与える必要があるってこと。制限はまだあるけど、もっと遠くまで行けるようになる。俺の経験では、基盤に計画と知恵を注ぎ込むほど、実際の建設にはあまり知恵や計画が必要なくなる。

└

もし基盤がAI自身によって作られたら、どうなるの？その場合は言い訳はないよね？

└

俺も同じことを発見した。質の悪い契約者のコードをリファクタリングしてるんだけど、最初はCodexが貧弱で局所的な修正をしてた。基盤を再設計した後（ブートストラップを捨てて、使いやすいフォームフィールドを作り、ハードコーディングされた役割の参照を修正して、TypeScriptの型を統合するなど）、具体的な指示なしでもずっと良い選択をするようになった。でも、Codex/Claude Codeは全ての問題を解決するわけじゃない。コードベースを理解して、コアの抽象を修正するために時間をかける必要がある。そうしないと、ただゴミの上にゴミを積み重ねて、パッチを当て続けるだけで、コアの問題を実際に解決することはできない。

└

ここでの難しさは、AIが真のグローバルビューを持っていないことだね。だから、特に人間のフィードバックやレビューなしで動かすと、良い構造でさえ徐々に劣化していく。でも、良い構造が本当に助けになるのはその通りだね。

└

AIは、質の悪いコードベースのリファクタリングを手伝えるのかな？少なくとも、基準が低いデザインを広く調査するように頼んだら、改善のための良い提案をしてくれる？ほとんどのコードベースは言う通りかなりひどいから、これはかなり重要なポイントだよね。

└

俺の経験そのままだな。AIは新しいプロジェクトをゼロから始めるときに特に脆い。今、macOS用のNNTPクライアントを作ってるんだけど（AppKit使って）、なんでかって言うと、最初はAIに何をさせるかをすごく慎重に計画してプロンプトを出さないと、狂っちゃうから（統合テストは必須）。今は読み取り専用モードができてて、その上に簡単に何かを作れるようになった。あと、GPT-5.3にはたくさんのスキルを教えなきゃいけなかった。

└

脱線するけど、良いベースってよく聞くけど、実際には見たことないな。自分だけが作業してるプロジェクトや、自分だけがクライアントで、範囲があまりにも厳格で、正直言って無駄なもの以外は、そんな神話のようなベースは存在しない。時間が経つにつれてニーズは変わるし、計画に固執することはできないことが多い。しばしば、大きな部分を再考する必要がある変更が起こる。私たちが嫌うタイトな結合は、元の要件に対して効率的なコードだっただけ。そうなると、時間や機会のコストと品質の損失の比較になる。時間と機会は常に勝つ。なぜなら、私たちは人間が運営する世界に生きていて、彼らは混沌としていて計画に従わないから。私たちの現実のシステム（官僚制度、政府のプロセス、リストは続く）も完全に自動化されることはなく、常に人間が介入する隙間を残している。特別なケースや例外は常にある。完璧に設計されたコードと、実際に機能するコードには現実世界での違いはない。長期的なメンテナンス性？君のコードは真空の中で動いてるわけじゃない、他のものに依存してるし、その出力も他のものに依存されてる。変化は現実だし、エントロピーも現実だ。君自身も、完璧なコードを書く完璧なプログラマーであっても、最終的には屈服して、これを後悔することになる。なぜなら、君自身が時間や機会と理想の間で選択しなければならなくて、間違った選択をしたから。俺のブログみたいなHNコメントを読んでくれてありがとう。

└

どうやって「良いコードの基盤」なんてものがあるって分かるの？それを持ってるかどうかもどうやって知るの？これはエゴから来る議論だね。

└

マルチプライヤーって言うけど、どんな数字のことを言ってるの？すぐに修正が必要ない機能がどれだけ出荷されたか、経験したことある？

└

完全に同意するよ。最近初めて「AIネイティブのコーディングプロジェクト」をやったんだ。今のところ、$20/月のChatGPTサブスクリプションでCodex CLIを使っても制限にぶつかってないし、会社からはみんな$800/月のClaudeの予算が与えられたからね。実装を始める前に、まずは1. ビジネス要件を含む初期の営業契約を作成した。2. 営業と話して得たメモ 3. 初期の発見コールのトランスクリプト 4. よくラベル付けされたデザイン図（クラウドアーキテクチャと各ラムダの役割） 5. デザインレビューのトランスクリプトと自分の説明、質問への回答 6. PMOのためにやらなきゃいけないエピック/ストーリーとタスクのChatGPTアシストによるブレイクダウンを作成した。その後、セッション中にMarkdownで詳細なブレイクダウンを出すようChatGPTに指示した。それがAGENTS.mdファイルのスタートだった。すべてのタスクを一つずつ進めながら、Codex/Claudeにコーディングをさせて、何をしたか、何をどう変えてほしいか、その理由を別のmdファイルに更新するように指示した。私の後に入る開発者は、最初のgit initからプロジェクトの完全なコンテキストを持っていて、彼らとエージェントたちは、決定の理由を理解できるだろう。GenAI以前に行われたプロジェクトについて、そんなことが言える？

どの部分も難しくなってないと思うよ。むしろ、人がキャリアの中で無視してきた「難しい部分」を浮き彫りにしてるだけ。ここ15年のソフトウェア開発は「人間の感覚でコーディング」だった。理解せずにSOからスニペットをコピー＆ペーストして、計画もなし、常に再アーキテクチャリングして、ノートパソコンで動けば本番にコードを出してた。今、AIがそれをやるようになったら、急に人々は仕事を計画してテストを強制したいって？これはウィンウィンだと思う。たとえ開発が遅くなっても、それは良いことだよ。結果として、より良い品質が強制されるから。

発音音韻論とソリトン物理学を結びつける論文に取り組んでるんだ。発話のジェスチャーは、ソリトンが衝突を乗り越えるのと同じように、共発音の重なりを生き延びる。音声学の文献にある非線形ダイナミクスは、ソリトン方程式と構造的に同じなんだ。誰も気づかなかったのは、この分野が会議を共有してないから。記事の簡単/難しいの区別は正しいけど、「難しい」の上限が低すぎる。AIが可能にする本当に難しいことは、より良いタイムゾーンのバグ調査じゃないよ（笑）。それは、どの人間もまたがることができない学際的な境界を越えて作業することなんだ。

個人プロジェクトで、特定のファイルにテストを追加するようAIエージェントに頼んだんだ。そのファイルはリクエスト前に500行、後に100行になった。なぜ他の内容を全部削除したのか聞いたら、削除してないって言われた。そしたら、そのファイルは存在しなかったって言われた。Gitの履歴を見せたら、謝って、最初にファイルが存在するか確認すべきだったって言った。はは！昨日、エージェントが「忘れておいて」と言った後に計画ファイルを削除したんだ（つまり、放っておいてほしいってこと）。

└

こういう失敗は、ツールが良くなるまでは仕方ないよね。価値を得るためのコストとして、時々厄介な編集を元に戻さなきゃいけないのは受け入れてる。バージョン管理があれば、ずっと小さい問題だし。

「スプリントのマラソン」っていう考え方が今やどこにでもあって、AIはそれを120%に引き上げてるよね。休まずにずっとスプリントし続けられる開発者がどれだけいるのか、ちょっと疑問だな。AIは助けになるかもしれないけど、監視なしだとすぐに脱線しちゃうし、自分が書いてないコードを読むのは、自分のコードを直すよりも疲れるよ。

他の人のコードを読むのは、自分でコードを書くよりずっと難しい。LLMコーディングについての議論でこの感覚が繰り返されてるのをよく見るけど、なんでそんなことになるのか不思議だよ。私が朝一杯かけて調べて書くような関数は、読むのに10分か15分もかからない。何かが正しいかどうかを確認するのは、最初から正しいものを考え出すよりも明らかに簡単だよね。もしコードを読むのに書くより時間がかかるなら、チームはほとんどの時間をコードレビューに費やしてるはずだけど、実際にはそうじゃない。じゃあ、この考えはどこから来てるの？

└

何かが正しいかどうかを確認するには、それがなぜ正しいのかを理解しなきゃいけない。それがコードを書く上での99%なんだよ。

└

編集者と読者の違いだと思ってる。言った通り、コードを読むのは結構簡単だよね。これにはめっちゃ同意する。プロとしてCを書くわけじゃないけど、Cの開発者が何をやってるのかはなんとなく読める。でも「編集者」だったら、実際にコードの流れを理解するために時間をかけて、コードを調整してみたり、何がもっと良くなるかを考えたり、編集しながらいろんなリファクタリングのアプローチを試してみる。どうやってこれをより良く書き直せるかを実際に見ていくのは、かなりの努力がいるけど、ただ読むのとは全然違うよね。これを表すのに「編集者」と「読む」以外の、開発者の分類も含むような言葉が必要だと思う。

難しいバグの診断は「難しい部分」とされることが多いけど、コーディングエージェントはそれが得意みたいだよね？だから、これが良い指標かどうかは分からない。AIは得意なこととそうでないことがあるけど、その境界はそんなに単純じゃない。

調査、文脈の理解、仮定の検証、特定のアプローチがこの状況にとって正しい理由を知ることが難しい部分です。 そうだね。別の言い方をすると、それは価値のある部分だよ。AIツールは高価値な作業と低価値な作業を区別するのが得意だね。