Rebuild: 410: Hitting the Context Window Limit (naoya) を聞いたメモ。

miyagawaさんとnaoyaさんがAI談義をする回。

AI

  • 2025年5月、Claude code のイベントがあり、みんな Claude Code に関して騒ぎ始めた
  • miyagawa: パーソナルな開発で使い始めた
    • Pro プラン ($20) で使っている
    • Opus でなく、 Sonnet だけでOKであれば Proプランで十分
  • naoya: 会社では Claude Code Team プランに入っている
    • Opus ガンガンに回す人だけ MAX プランに切り替える財テクしている
  • miyagawa: オープンなモデルに投げるの禁止だったが、AWS Bedrock & Google Vertex AI 経由で Claude Sonnet, Genmini 2.5 は使えるようになった
    • Bedrock は AWSで認証可能
  • miyagawa: Sonnet で困ったことはない
    • コードレビューで使っている
      • PR submit する前にレビューしてもらう
    • Claude Code にPR全部書かせるのにトライした
      • Claude Code はワンショットの成功率が高い
    • 1回目は全然求めるコードではなかったので、指示を変えて再度投げた
      • 大きい変更だったので、小さい単位でコミットして、という指示を出したら求めるものが出来た
    • ワンショットで頑張りたいのであれば Opus 使えば良くなる
  • 生成AIはRustが苦手？
    • miyagawa: Claude Code でRustを書かせている限りは、Rustは得意そうに見える
      • Rust はコンパイルエラーが詳細なので、頑張って直してくれる
    • エラーを再帰的に参照して修正する
    • (Huskell はダメらしい)
  • miyagawa: コメント・変数が冗長なので、 Claude.md で「変数短くしろ」「当たり前のコメント書くな」と書いている
  • 仕事のコードだと、他のコードベースを参照しつつ進めてくれるので、うまくいきやすい
  • Claude は人間がやりそうな仕事の進め方をしてくれる
    • まずはTODOリストに分割
    • いきなりコードを書くのではなく、既存のソースコードを調査したり、コードサブタスク分割して進める
    • シニアエンジニアの振る舞いをシミュレートしている印象
  • Claude は Shift Tab 二回でプランニングモードになる
  • あまり、1つのセッションで長々と書かないほうがいい
    • コンテキストのリミット到達
    • あとで同じミスに巻き戻ったりする
    • 失敗したら
      • やり直す
      • Plan.md に途中経過を書かせ、新しいセッションに続きをやらせる
      • ! でbash modeに入るので、git diff main で作業Diffを表示し、それをコンテキストとして保持してもらう
        • いわゆるコンテキストエンジニアリング
    • 人間もプログラミングを長々とやっていると、わからなくなることはよくあることだ
      • 始めにやろうとしていたこと・やっていたことを忘れる
      • 過去の間違った情報をコンテキストとして保持し続けてしまう
        • 途中の状態をdumpして1からまたやり直させるのが吉
    • 人間の場合
      • 次の日再開すると問題が解決する、散歩に行くと開放が思い浮ぶ etc.
      • コンテキストが溜まってくると、視野が狭くなる
      • 競プロの問題をAIに解かせるて、AIが解けないモードにいったん入ると、スタックしてしまう
  • AIへ依頼するタスクは小さい方がいい
    • but, ウルトラマイクロマネジメント方針で、タスクを小さくすればするほど、「自分がやった方が早い」となる
    • どれくらい小さくすれば、人間とAIがエネルギーを最小限にできるか、この塩梅を探る必要がある
  • miyatawa: Rust 早く書けない
    • こういうの書きたいというのが分かっている時に AI に書かせるのはめっちゃ楽
    • 人間が 5分 かかるのが、AIだと 5秒 で終わる
  • それだと人間がいつまでたってもコードを書けるようにならないのでは？
    • コーディングスキルの筋トレ問題
    • 「goわかんないけど、Claude Code でなんか動くものができました」
      • 反対意見:
        • ソフトウェアエンジニアリングはクラフトマンシップだ！
        • そんなことしてたらいつまでも自分で書けないじゃないか！
        • 生成AIを使うのは倫理的に良くない！　電力の無駄だ！
    • AIを使うのが MUST という会社も増えている
      • AIで調べてからじゃないと、ヘッドカウントを増やせない
    • AIがなくなる未来がないと仮定すると、別に人間のコーディングスキルは必要ない、AIにずっと書かせ続ければいい
  • naoya: Claude Code Action を活用している
    • GitHub issue → PR作成をやってくれる
      • 「@claude これやって」でやってくれる
    • Out of memory のエラーに出くわした
      • 一瞬で解決した
      • debug print 文をClaudeに食わせる
      • コードと突合して原因を特定した
    • ただコレをやるには人間の直感が必要
      • この直感を涵養するには、ソースコード読む、ずっとチームにいて第六感が働くようになる、みたいな経験が必要
      • だからAIにコードを書かせ続けるのは、この直感が育たなく問題なのでは
  • miyagawa: ソフトウェアエンジニアリングにおいてコードを書くのは一部である
    • ソフトウェアエンジニアリングはデプロイ、モニタリング、運用、デバッグ、修正の一連のサイクル
    • コードを書くのは、本質的なものはない
  • naoya: 書く行為に意味があると感じている
    • AIにコードを書かせ続けていると、自分がバカになっていると感じる
    • miyagawa: マイクロマネージしている
      • 自分で書けよ！と思われるかもしれない
      • 自分で書くより、AIに書かせた方が早いのでそうしている
      • 3,4ヶ月前まではよくわかんないものが出来て「自分で書いた方が早い！」となっていたが、今は違う
  • miyagawa: production で 1日に数回謎のクラッシュする事象があった
    • Claude Code に食わせたら原因が特定できた
    • AIのためにログを取れるようにするのは重要
  • naoya: Google Cloud SQL に SQL Insight がある
    • 遅いクエリをGitHub Issue に貼って Claude に対応させると、改善提案してくれる
    • データとソースコードが一緒になるとAIは強い
  • miyagawa: Claude Code はCLI なところがいい
    • Linux で入る。Docker コンテナ内でも入る。開発者フレンドリー。
    • MCP 入れるよりコマンドラインを叩けるようにしたほうがいい
      • gh コマンドを叩かせるのが良い
  • Claude Code CLI と Claude Code Action の使い分け
  • AI時代はモノレポが有利？
    • レポジトリ1つだけで、AIがいい感じにコンテキストを読み取ってくれる
  • 新規で作らせる vs 既存のコードをいじらせる
    • Vibe Coding で欲しいものを作らせたい vs プロとして開発している かの違い
    • 後者はデカいソースコードが対象
      • コンテキストの明示が大事
      • このPRを見ろ、すでにあるものを真似しろ、はほぼうまくいく
  • 謎のLLMノウハウが溜まっていく
    • AIバッドノウハウ知らなくても作れるようにはなっていくだろう
  • GitHub 落ちたら仕事できない、というのと同じように、Claude Code 落ちてて仕事できないが発生しそうw
  • gemini CLI と Clude Code をインテグレーションしている人がいた
    • 自分で検索して情報突っ込んだ方が早い
  • 経営側として見ていて、一ヶ月かかっていた仕事が3日で終わるようになったかというと全然そうなっていないと感じる
    • 一週間かかっていた問題がたまたま1日で解決できるようになりましたはある
    • 10-20%くらい生産性の向上は感じる
    • エンジニアが少なくても大丈夫！という現状には全然なっていない
  • シニア・プリンシパルの人はそもそもコード書く時間が取れない
    • コードを書く作業は時間がかかるもの
      • これを短縮することができるのでは
    • AIは気兼ねなくビルド & スクラップがしやすいのが良い
      • 人間の場合、どうしてもサンクコストが働くので…
  • AIで1日かかってた作業が10分で終わるとしよう
    • 浮いた時間を別のタスクに使おうかってなるかというと、そうはならない（疲れるから）
      • 速く仕事上がったり、コーヒー飲んだり…
    • 結局人間がボトルネックになり、生産性は上がっていない
    • 週休3日みたいなことにはならず、空いた時間をダラダラ働くだけになるのでは
      • （パーキンソンの法則..
  • miyagawa: リリースマネジメントをClaudeにやらせる
    • けっこうマニュアルな部分（Click Ops）がある
    • グリーンになったらApprove ボタンを押すみたいなのを手順書を書いてClaude Codeにやらせるとやってくれるようになった
    • 人間への説明の時に必要な手順書と一緒のアウトプットではある
    • 自動化は面倒なのでみんなやっていない
      • Claude はエラーにぶち当たっても柔軟にやっている
    • 精神衛生上良くなった、その時間を有効活用できてているかというと…?
    • 同僚とディスカッションするのをLLMと壁打ちできるようになって、コミュニケーション疲れは減った
  • モデルの性能が半年後格段に上がると、全く違う話をするようになるのかもしれない
  • スクショからカレンダーに登録するコード、スクレイピングするコードがVibe coding で一瞬でできるようになった
    • 若い時はそれ自体が楽しいタスクになったが、散々やるとただ面倒くさいという感情のみが残る
    • 普段使っていない環境のセットアップで1日が溶ける
      • 仕事で触っていないnodeのセットアップとかが大変
    • pythonだとuvが熱い
    • 趣味のコードまで、色んな言語の最新のイケてるセットアップが完璧に出来ている必要はない、VibeでOK
    • デプロイとかセキュリティ周りはまだAIがカバー出来ていない部分
      • シニアになると、デプロイとかはどうでもよくて手元で動けばいいや、という気持ちになる