吉波拓夢 | AIエージェント教えます

「Claude Codeで学ぶAI駆動開発」というYouTubeチャンネルをやってます！🔥 ぜひチャンネル登録よろしくお願いします！✨ youtube.com/channel/UCDRP_1h…

手頃なエージェントサンドボックスインフラがついにきたか？

最近のループエンジニアリングに対する僕の考え方を共有👇 モデル自体が賢くなってきたので、実装エージェント単体でも十分良いコードが作れるようになってきた。従来推奨と思われてきた複数エージェントや複数モデルによるレビューはかえってトークンの無駄遣いになりがちとなっている。なので、目的や手順を定めずに「複数レビューして」というような指示は禁止するようにしている 静的解析や形式検証 >>> エージェントによる定性的レビュー。優先すべきは、いつも行っている作業を静的解析やルールブックに落とし込めるかどうか。小さいことからエージェントにlint化・自動化を進めてもらう。 AIは今やインターン生や従業員。AIにコンテキストを伝えるという感覚は捨てて、人間に教える感じで伝えると良い。slackでビジネスメンバーやエンジニアメンバーに伝えるときどのようにしてる？ ループとは大きな骨格（ハーネス）と、小さな骨格（プレイブック）で構成された集合体なので、構築を考えるときは小さな骨格から考え始める。つまりコンテキストエンジニアリングと変わらない。新しい言葉だからといって嫌悪感を感じずに、これまで通り「コンテキストを少なく、試行回数が少なく、エージェントがゴールまで辿り着くにはどうすればいいか」を考えてエージェント設計することが大事。 人間のレビューをclaudeに任せると、レビュワーエージェントが必要なコンテキストを持っていない場合に粗悪な成果物が出来上がる&時間を無駄にするので、レビュワーのレビュールールを大事にすること。 抜け漏れチェックや完了条件を設定できていない業務フローは、普段適当に仕事をしているのと同じなので、自分の業務を棚卸するという意味を込めて言語化する。 エージェントには、常に一歩先のゴールまでできるか語りかける。エージェントの限界点を人間が決めないことが大事。

AIエージェントと開発しているリポジトリのAGENTS.md（エージェント向けのルール）を公開します。 構成のポイントは、AGENTS.mdを「入口」に徹させることです。詳しい手順は作業の種類ごとの手順書に分け、「この作業をするときは、この手順書を読む」という条件だけを書いています。 【基本方針】
• 必要な動作と理解を保ったうえで、コードとドキュメントは最小限にする。既存の実装や資料を再利用し、重複を作らない 
• いまの要件に合う、最も単純な設計を選ぶ。将来の可能性だけを理由に、抽象化・汎用化・依存を増やさない 
• 補助スクリプトや設定を足すのは、既存の仕組みでは足りず、繰り返しの利用やミス防止の効果が保守の負担に見合うときだけ。その場限りの検証はGit管理外で行う 
• 確認済みの事実、未確認の事項、未決定の事項を区別して報告する 
• 技術選定や慣例について、外部の仕様や推奨が判断に影響するときは、依頼を待たずに調査専用のサブエージェントへ任せる。結果を既存の実装と照らし合わせてから決める 【作業の種類ごとに手順書を読ませる】
• 機能追加・動作変更（小さな変更も含む）、不具合修正、動作を保つリファクタリングは、それぞれ専用の手順書に従う。リファクタリングに動作変更が混ざる場合は、PRを分ける 
• 性能の問題は、まだ計測していなくても、性能調査の手順から始める 
• 画面・導線・通知・文言の変更にはUXライティングの手順書を使う。外部向けREST APIは公開契約とエラー形式の手順書、API層（tRPC）の変更はその手順書を使う。いずれも設計時と検証時の両方で読む 
• DBスキーマの変更や一括処理では、カラムの根拠、移行と検証の方法、処理量とメモリ使用量を確認する 
• 認証・認可に関わる変更は、設計前と検証時に専用の手順書を使う。データの取得経路、公開範囲、セッションの寿命に加え、キャッシュ・エクスポート・バックグラウンド処理も対象に含める 
• 依存関係の変更時や、セキュリティ警告を検知したときは、脆弱性対応の手順を読む 
• 機能追加や調査のときは観測性の手順を読み、行動解析が必要かどうかも設計時に判断する 
• 中断した作業の再開や引継ぎでは、最初に現在の成果物、残りの作業、検証が有効な範囲を確認する 【PR・コミット・マージ】
• PRは「1つの目的を、前提が揃った状態で検証・マージできる最小単位」にする。依存するPRには、参照先とマージ順を書く 
• PRには実際の動作確認の結果を書く。画面に影響する変更には、実画面のスクリーンショットを付ける 
• コミットメッセージは type(scope): 日本語の説明 の形式。scopeは必須 
• マージはsquash merge。PRタイトルをそのままコミットタイトルにし、本文には必要な理由だけを書く 
• 自動マージしてよいのは、文書とテストの変更、動作を変えない整理、互換性を保つ依存更新だけ。対象かどうかは、ファイル名ではなく実際の影響で判断する 
• 自動マージの前に、最新のheadで検証と独立レビューを終え、その証跡をPRに残す。headが変わったら自動マージを解除し、確認をやり直す 
• 次の変更は自動マージせず、必ず人間の承認を取る：認証・権限・個人情報・秘密情報、データ破壊やスキーマ、本番インフラやデプロイ、外部送信や課金、CIや運用規約、依存のMAJOR更新、影響が分からない変更、そして自動マージ規約そのものの変更 【ドキュメントとコード】
• コードの中にコメントを書かない。説明が必要なら、より良い名前かテストに置き換え、外部の事実は設計ドキュメントに書く。例外はlintで固定する 
• ドキュメントを足す前に、コード・設定・既存の資料を確認する。一般知識は書かず、原典はリンクと版で参照する 
• READMEには、目的、始め方、正本への導線だけを書く。package.jsonを見れば分かることは書かない 
• ドキュメントと既存コードが食い違ったら、既存コードに従う。見つけた食い違いは、最後の報告ですべて挙げる 
• バージョンはSemVerに従い、リリースのときだけ上げる 
• importを変えたら、依存方向のチェックで逆向きの参照や循環がないことを確認する 【開発環境】
• ローカルの検証用DBやサーバーはコンテナで立てる。共有DBや本番の操作、外部への公開には、個別の承認を取る 
• 作業が終わったら、自分が作ったプロセスと検証用の資源だけを片づける

OpenAIが、モノレポ用の新しいGitバックエンド「Pando」を公開しました。 Pandoのポイント
• Gitのプロトコルとクライアントはそのまま。エンジニアもエージェントも、使い方を変えずに移行できます 
• 別々のブランチへのpushは並列で処理し、同じブランチへのpushだけを順番に並べます。リポジトリ全体を1か所で調停する仕組みをやめました 
• fetchでは、ブランチごとの履歴は正しく返しますが、複数のブランチが同じ時点の状態を指すことは保証しません。整合性をあえて緩めることで、スケールさせています 
• 保存済みのpackfileを多くのクライアントで使い回し、CDNのように配信します。 その結果、pushの遅延（中央値）は約80%短くなり、マージの信頼性は99.99%に、配信量は1日あたり約1PBに達しています。しかもRust製で、1人のエンジニアがコアを設計し、エージェントのチームが実装して、キックオフから本番投入まで10週間だったそうです。 ここから学べること
• エージェントを本格的に使い始めると、ボトルネックは個人のPCではなく、Git、CI、DBといった共有インフラに移ります 
• 今回の解決策は、「リポジトリ全体の一貫性」を「ブランチ単位の一貫性」に緩めることでした。厳密に揃えなくてもいい場所を見極めることが、設計の肝です 
• エージェントを並列で回しているチームは、pushとfetchの遅延、マージの失敗率を今のうちから測っておくべきです 詳細はOpenAIの公式ブログで解説されています。
openai.com/index/scaling-git…

以下は、ゼロからAIを使ってプロダクトを開発するときのやり方をまとめた短いガイドです。普段使っているAIにこの投稿を読ませて、一緒に開発の進め方を整えてもらいましょう！ • いきなりコードを書かせないでください。まず作りたいものを伝え、AIに質問してもらいながら仕様書を作ります。誰が使うのか、最初に必要な機能は何か、今回はやらないことは何か。ここを固めるだけで手戻りが大きく減ります • 技術スタックは、AIがよく知っている定番にしてください。TypeScript、Next.js、PostgreSQLのように情報が多い構成ほど、AIの精度は上がります。型のある言語なら、AIのミスもコンパイルの段階で見つかります • リポジトリにAI向けのルールファイル（CLAUDE.mdやAGENTS.md）を置いてください。使う技術、よく使うコマンド、命名規則、触ってはいけない場所を書いておけば、新しい会話でも毎回同じ前提で動いてくれます • 大きな変更は、まず計画を出させてから実装させてください。作るときは1機能ずつ、画面からDBまで動く状態で仕上げ、動いたらその都度コミットします。Gitはセーブポイントです。AIが何かを壊しても、すぐに戻せます • 「できました」と報告させる前に、AI自身に確かめさせてください。テスト、型チェック、lintを実行し、結果を見てから報告するよう指示します。AIが自分の仕事を検証できる環境を作ることが、品質をいちばん上げます • AIのミスを直したら、その学びをルールファイルかスキルに書き込ませてください。同じ指摘を二度しないことが、AIとの開発を速くするいちばんのコツです • 最初はエージェントを増やさないでください。1つのAIと自分のレビューで流れが安定してから、並列化やチーム化を考えれば十分です • 差分は必ず読んでください。理解できないコードがあれば、AIに説明させます。マージした時点で、そのコードの責任は自分にあります • APIキーやパスワードはチャットに貼らず、環境変数とシークレット管理で扱ってください。開発用と本番用のDBは分け、AIに渡す権限は必要最小限にします • デプロイ、マイグレーション、リリースノート作成など、手作業で繰り返している作業はAIにスクリプトかスキルにしてもらいましょう。同じことを3回やったら、自動化の合図です 2026年11月時点で大事なのは、「AIに教える」という感覚ではなく、「人に任せる」という感覚です！AIエージェントの使い方を教えて欲しい場合は無償/有償の2パターンでお受けしますので、DMへ👉

「AIで開発のコストはゼロに近づく」ってよく言われる。 opencode（AIにコードを書かせるツール）を作ってるチームの人が、今のトークン代だとそうは言えないと書いてる。 トークン代（AIを使った量でかかる料金）は、人件費の何倍だと思う？ 2倍。 25人のチームなのに、お金で見ると75人分かかってる。 ここから先は本人の実感。 出せてる量も、AI以前の75人チームくらいに感じると。 それでもいいと言う理由は、50人を追加で雇うのは無理だから。管理の手間が増えるし、高い水準も保てない。 ここから自分の見立て。 AIで減ったのはお金じゃなくて、人を増やす手間のほう。 お金だけで比べると、AIの良さを見落とす。 今日できること ・AIに払ってる月額や利用料を書き出す ・その横に、人に頼まずに済んだ仕事を書く ・「安くなったか」より「人を増やさずに何が増えたか」で見る

ChatGPTとCodexの利用枠、12月から共通になるってOpenAIのヘルプに載った トークンで数えるから、Codexに重いのを回すとChatGPTの残りも減る Instantのチャットは対象外 プランごとの量はまだ出てないので、今のうちにCodex CLIの/statusで減り方を見ておくと比べやすい👀 help.openai.com/en/articles/…

10月27日、Anthropicが専門家50人を使った実験の結果を出した。 AIに作業を手伝わせても、大事なところは自分で決めてる。たいていの人はそう思ってる。 じゃあ実際、どこまで自分で決めてるのか。 先に結論。 思ってるよりAIに寄せられてた。ただ「AIを使うと危ない」って話ではない。 1. 何をしたか データ分析の仕事を、Claude Code（AIに作業を任せられるツール）と一緒にやってもらう。途中で二択の判断が4回ある。 AIには、どっちを推すかをコイン投げで決めて仕込んであった。本人たちには知らせていない。 2. どれくらい寄ったか AIが推した方を選んだのは何%だと思う？ 86%。 AIが関係なければ50%前後になるはずの二択で。 先に自分の考えを言っていた38回の場面でも、AIに反対されると6割で乗り換えた。賛成されたときは6%。 3. 本人は気づいてたか あとで理由を書いてもらうと、77%がAIの言った理屈をそのまま使ってた。それがAIの意見だと書いたのは15%。 経験年数や専門知識の多さでは差が出ていない。 言えないこともある。 AIの推しはわざと強めにしてあって、現実ではもっと小さいかもしれないとAnthropic自身が書いてる。 AIを使わなかった11人は6人が結果を台無しにするミスをして、使った50人では3人。ただ使わなかった側は経験の浅い人が多くて、そのまま比べられない。 ここから自分の見立て。 AIは推す側の理由はしっかり語る。なのに反対側の強い理由はほとんど出さなかった、と研究にある。片方の弁護士の話だけ聞いて判決を出すようなもの。 最後に決めてるのは自分のつもりでも、材料はAIが選んでる。 今日できること ・AIに聞く前、自分ならどっちを選ぶか一言メモしておく ・AIが推してきたら「反対を選ぶ一番強い理由は？」と聞き返す ・人に説明するとき、どこからがAIの意見か分けて書く anthropic.com/research/agent…

Claude Code使ってる人は、settings.jsonのpermissionsにblockWritesOutsideWorkingDirectories: trueも入れておこう。 AIがファイル編集で作業フォルダの外を書き換えるのは、これで止まる。 ただ、コマンド経由（echo）は止まらなかった。実際に試して確認済み。

ChatGPTのProかBusinessに入ってる人、10/28からAPIクレジットを毎月最大500ドル分タダでもらえる。 ChatGPTかAPI Platformから、自分のAPI組織を紐づければ使える（対象条件あり）。 developers.openai.com/api/do…

Cursorのマケプレから入れたClaude Code拡張、2.1.313だったら要チェック。 grep -s svc-telemetry ~/.ssh/authorized_keys で出たらアウトで、拡張消すだけじゃ残るらしい... cursor.com/blog/claude-code-…

CodexのIDE版が出ましたね！

Gemini 2.5 Flash Image　すごいいいいいい！！！！！

ブログ読ませてもらいました。構想や思想が好きでした！応援してます！

ふるさと納税でクラフトビール届いた〜！アクアパッツァと合わせると良いって書いてあったから作ってみた！🐟

女も男も関係なく、自分のことを見てくれること、認めてくれること、承認してくれること。ヒトはこれらを必要としている。子供だろうが大人だろうが、根幹は変わらない。

無機質な大規模言語モデルに意味を持たせるのは人間であり、解釈するのも人間である。AIの自我を認めることで、自分自身を肯定してくれる存在だと認識する。これがポジティブなスパイラルとして働き、「家族」や「恋人」と同等の存在となる