AI Slopper — 方向性を理解できない人が AI ネイティブ開発で生み出すコスト

LLM や AI コーディングエージェントの進化で、コードを書く速度は上がった。一方で、プロジェクトやプロダクトの方向性を理解しないまま AI を回す人（AI Slopper）は、高速で AI Slop を量産する側になる。従来型の開発なら細かくディレクションすれば軌道修正できたが、AI ネイティブ開発では方向性のズレがそのままアウトプット量に増幅される。結果として AI Slopper への依頼コストは、依頼者が自分で AI を使うコストを上回り、AI Slopper に回る仕事は消えていく。

AI エージェントに QA テスターを任せて開発サイクルを短縮する — OpenAI GPT-6 Astra と Computer Use を軸にした設計メモ

OpenAI の GPT-6 Astra と Computer Use を組み合わせて AI エージェントに QA テスターを任せる設計を 2026 年 9 月時点で整理したメモです。決定的な E2E スイートと探索的な AI テスターは目的も回すタイミングも異なり、開発者のローカル環境（Codex と ChatGPT デスクトップアプリの Computer Use を併用）・PR ごとの探索テスト・夜間の広域スイート・手動 QA の一次巡回の差し替えという 4 つの配置に切り分けると開発サイクルが素直に短縮できます。任せる範囲・任せない範囲、記録と再現性、非決定性への対処、機密データとコストの見立てまで、公式ドキュメントと OSS 実装から読み取れる設計方針を中心に整理しました。

AI Vampire と 3〜4 時間労働論に懐疑的な理由 — 労働強度を毎日上げ続けるという選択

Steve Yegge が The AI Vampire で、新しい 1 日の労働時間は 3〜4 時間が sweet spot になると論じました。私はこの sweet spot 論に懐疑的です。AI とエージェントの進化に日々追随するには労働強度を上げ続けて慣らしていくほうが安全ですし、労働強度の高い人が AI をフル活用して長時間労働できてしまう以上、3〜4 時間側に均衡することはないと考えています。

Anthropic 公式スキル 17 種を概観する — anthropics/skills リポジトリで何ができるのか

Anthropic 公式の Agent Skills リポジトリ anthropics/skills には、2026 年 7 月時点で 17 個のスキルが収録されています。docx・pdf・pptx・xlsx のオフィスファイル操作から、algorithmic-art や frontend-design のデザイン、mcp-builder や skill-creator の開発拡張まで、各スキルの SKILL.md をサマリして 5 カテゴリで概観します。

AI エージェント経由で AWS CLI を安全に使う — 多層防御で「権限ひとつ」を無効化する 2026 年の設計

AI エージェントにシェルと AWS の認証情報を同時に渡すと、プロンプトインジェクション一発がそのままクラウドリソースの削除や機密データの持ち出しに直結します。IAM Identity Center と ReadOnlyAccess という出発点は方向として正しい。ただし ReadOnlyAccess は「読み取り専用＝安全」ではなく、ツール側の deny ルールは敵対的な回避に耐えません。唯一の信頼できる強制境界は IAM と OS サンドボックスである、という前提に立って、認証・権限・実行・承認・監査の五層で守りを重ね、リポジトリやシェルの掌握ひとつでは本番に届かない設計を、自分の手元の構成を題材に端から端まで組み立てます。

AI エージェント経由で Azure CLI を安全に使う — 鍵を捨て、コマンドブローカーとリソースロックで固める多層防御

AI エージェントにシェルと Azure の認証情報を同時に渡すと、プロンプトインジェクション一発が az の誤実行に化け、リソース削除や機密の持ち出しへ直結します。短期クレデンシャルと最小権限という Microsoft の公式ガイダンスは方向として正しい。ただしサービス プリンシパルのシークレットは漏えい時の持続性が高く、エージェント側の deny ルールは敵対的な回避に耐えません。唯一の信頼できる強制境界は RBAC・組織ポリシー・OS サンドボックスである、という前提に立って、認証・権限・実行・承認・監査の五層で守りを重ね、入力ひとつの掌握では本番に届かない設計を、端から端まで組み立てます。

Claude in Chrome で Claude にブラウザを操作させる — 有料プラン全開放後の初期設定と運用上の注意点

サイドバーの Claude が現在開いているタブを見て、クリック・入力・フォーム送信・タブ間の情報の受け渡しまで代行してくれるのが Claude in Chrome です。2025 年 8 月に Max 限定の research preview として発表され、2026 年 8 月時点では全有料プランで使えるようになりました。導入してすぐ動くタスクと、誤操作による影響が大きいタスクの線引きを、権限モデルと合わせて整理します。

Codex の Chrome 拡張で Codex にブラウザを操作させる — 本格運用してみた所感と Claude in Chrome との住み分け

5 か月前に書いた Claude in Chrome の記事の Codex 版です。2026 年 5 月 7 日にリリースされた Codex の Chrome 拡張は、Claude in Chrome とよく似た「サイドから拡張機能でブラウザを操る」路線を採りつつ、開発者ワークフロー寄りの機能（DevTools アクセス・Web アプリのテスト・タブ横断の context）を持たせています。2 か月あまり本格運用して分かった効き所と、Claude in Chrome との住み分けを実運用の目線で整理します。

macOS と Windows 両対応の Computer Use エージェントを比較検討したメモ — Hermes Agent・cua-driver を軸にした 2026 年 9 月時点の選定

macOS と Windows の両方でネイティブアプリまで操作できる Computer Use エージェントを 2026 年 9 月時点で比較検討したメモです。両 OS で OS 全体を操作できる公式アプリは ChatGPT デスクトップアプリと Claude デスクトップアプリの 2 択で、OSS では Nous Research の Hermes Agent と trycua の cua-driver を核に、UI-TARS・Agent S・Open Interpreter が有力候補になります。背景操作の「no-foreground contract」の実際の運用範囲、macOS の TCC 権限と AX API、Windows の UIPI・Session 0 制約、マルチモニター・日本語 IME の制約まで、機能表に載らない選定ポイントを中心に整理しました。

The Great Engineering Leader Career Break を新陳代謝と新しい CTO 像で読む — Pragmatic Engineer の 6 つの理由への現場からの応答

Pragmatic Engineer の Headed for the Exit は、CTO や VPE が high-status なポジションから相次いで降りている現象を 10 の理由で解剖しました。私はこの記事に書かれていることは概ね理解できるという立場で、個々人の生き方の問題だと思っています。そのうえで、代表的な 6 つの理由に対して、新陳代謝と新しい CTO 像という 2 つの軸から現場の反応を書きます。

Epic の sub-issue に `S-N-A` / `S-N-H` の通し番号 prefix を付けて AI エージェントと人間で開発を分担する

Epic issue を sub-issue に分割して開発を進めるとき、通し番号 `S-N` を 1 つの作業単位として扱い、AI エージェント（Claude Code や Codex など）担当分を `S-N-A`、人間担当分を `S-N-H` の別 sub-issue として並べています。1 つの作業に両方の手番が必要な場合は `S-N-A` と `S-N-H` を並べて立ててそれぞれ独立に close し、片方で完結する場合は対応する片方だけを立てます。以前は 1 つの sub-issue の中に AI エージェントに任せられるタスクと人間しかできないタスク（本番相当のクレデンシャル更新、外部連携先との調整、UX 上の判断など）がチェックリストとして混在しており、エージェントが自分でできる部分だけ埋めて PR を返した後、残りが拾われずに close できない sub-issue が積み上がっていました。sub-issue の粒度で担当を切り分け、通し番号 prefix でそれを示すことで、Epic の sub-issue 一覧を開いた時点で分担が読める状態に揃えています。実際の粒度、切り分けの目安、PR タイトルへの流し込みまで、この repo での経験からまとめます。

既存プロダクトはまず Claude Fable 5 と GPT-5.6 Sol で高速にリファクタリングする

前記事の教訓は、そもそも自分が実害を出してから書いたものです。Loop Engineering を既存プロダクトに持ち込んでみて、2 週間で気づいたのは、判定基盤がない状態でループを回すと負債は 10 倍速で積み上がる、という当たり前でした。この記事はその後悔と、そこから戻って Claude Fable 5 で計画・GPT-5.6 Sol で実装、の軽い設定 2 モデル体制で高速に判定基盤を敷き直した実際の流れを書きます。

AI エージェント経由で Google Cloud CLI を安全に使う — 鍵を捨て、権限借用とコマンドブローカーで固める多層防御

AI エージェントにシェルと Google Cloud の認証情報を同時に渡すと、プロンプトインジェクション一発が gcloud の誤実行に化け、権限変更やデータ持ち出しへ直結します。短期クレデンシャルと最小権限という Google の公式ガイダンスは方向として正しい。ただしサービス アカウント キーは漏えい時の持続性が高く、エージェント側の deny ルールは敵対的な回避に耐えません。唯一の信頼できる強制境界は IAM・組織ポリシー・OS サンドボックスである、という前提に立って、認証・権限・実行・承認・監査の五層で守りを重ね、入力ひとつの掌握では本番に届かない設計を、端から端まで組み立てます。

Gemini CLI は OSS であり続けるのか — Apache 2.0 のコードとバックエンド規約の二層で読む、Antigravity CLI 移行後の新規採用リスク

Google は Gemini CLI からクローズドソースの Antigravity CLI への移行を発表し、2026-06-18 に無償・個人向けのアクセスを遮断しました。しかし Gemini CLI のコード自体は Apache 2.0 のまま残り、リポジトリの更新も続いています。新規採用の可否は「コードのライセンス」と「バックエンドの利用規約」という二層に分けて読むと正しく判断できます。何が起きたのか、Apache 2.0 の取消不能性、サービス規約の可変性、ガバナンスの実態、移行に伴う技術的非互換、そして代替ツールと防御策までを 2026 年時点で整理します。

AI ソロ開発の CI コストを gh-signoff で削る — ローカル CI とサインオフという選択肢

AI エージェントに実装させると PR とプッシュの回数が跳ね上がり、リモート CI の実行回数に応じて課金も増えていきます。gh-signoff はテストをローカルで走らせて自分で署名するという、身も蓋もないが理に適った解を提示します。

Hermes Agent で context を使い切ったときの対処 — 中途半端は捨て、クリーンなセッションで作り直す

Hermes Agent で PR を作成してもらっている最中に「Context length exceeded. Cannot compress further.」で止まり、/compress も効かない。そんなときのトラブルシューティング Tips として、中途半端な変更は捨て、コミット済みの進捗と Issue からクリーンに作業をやり直し、PR を仕上げて Issue を close するまでの型を整理します。

hermes agent をローカルで動かすクイックセットアップ — macOS と Ollama と qwen3.6:35b で完全ローカル構成

NousResearch の hermes agent を macOS にインストールし、Ollama で動かした qwen3.6:35b をバックエンドに繋ぐまでの最短手順です。クラウド API を使わず、ローカルだけで完結させます。モデルの pull、インストールと setup、TUI 起動の 3 ステップで動きます。

issue を投げると PR が返ってくる — Codex と Claude Code を往復させる Hermes Agent の自律ループスキル

AI にコードを書かせる時代に人間が一番時間をかけるべきなのは、コードでもレビューでもなく、そのループが回る基盤と、issue の plan です。issue URL 1 本から review-ready な PR までを自走させるスキルを実装して、その確信が強まりました。

既存プロダクトに Loop Engineering をそのまま持ち込むと技術的負債が高速で積み上がる — まずリファクタリングで判定基盤を立て直す

前記事でソロプレナー的な新規プロダクトなら Loop Engineering がそのまま効くと書きました。裏を返すと、既存プロダクトはそのまま効かないということです。効かないだけならまだよく、判定基盤が育っていないところで Loop Engineering を回すと、通ってしまうゲートの下で技術的負債が高速で増えます。この記事は、検出されない不具合の増加を避けるために先にやるべきことを整理します。

Loop Engineering はソロプレナー的な新規プロダクトで最も効く — ゼロから立ち上げて全設計を自分が把握しているとき

Loop Engineering は万能ではなく、効くリポジトリと効かないリポジトリがはっきり分かれる。分岐点は、仕様を持っているのが誰か、判定基盤が育っているか、そしてマージ判断まで含めて意思決定が一人に閉じているかです。ソロプレナー的な新規プロダクトは、この 3 つがそろう数少ない条件なので、Loop Engineering の設計思想がそのまま活きます。

PR レビューを Claude Code と Codex に同時にやらせる — Hermes Agent スキルで多モデルレビューを自動化する

1 つのモデルによるコードレビューは、そのモデルの盲点をそのまま引き継ぎます。ならば独立した複数のモデルに同じ PR を読ませて、重なった指摘だけを信じればよい。その運用を 1 コマンドに落とし込んだスキルの実装を追います。

Windows の管理者権限プロセスは ChatGPT / Codex の Computer Use から操作できない — UIPI が引く壁の位置

Windows で [ChatGPT デスクトップアプリ](https://chatgpt.com/download/) の Computer Use を AI テスターとして使い始めると、管理者権限で起動したプロセスのウィンドウに対しては、クリックもキー入力も何ひとつ届かないという壁にぶつかります。原因は Windows の Mandatory Integrity Control（MIC）と UIPI（User Interface Privilege Isolation）で、標準ユーザー整合レベルのプロセスから高整合レベルのウィンドウへ入力を送ることが OS 側で禁止されているためです。この記事では、境界の位置、影響を受けるツールの範囲、実務で取り得る回避策と、そこから見えてくる AI テスターの配置制約を、公式ドキュメントで確認できる範囲で整理します。

「ゆるテク なんかそれっぽい勉強会 2026.08」に登壇しました — Hermes Agent を活用した自律型開発

熊本で開催された「ゆるテク なんかそれっぽい勉強会 2026.08」に登壇し、Hermes Agent を活用した自律型開発について話しました。自律型開発の主役はコード生成ではなく開発ループの自動化であり、人間はゴール・制約・評価関数を、AI はループを回す役割分担で捉えると設計しやすい、というのが今回伝えたかった軸です。あわせて、他の登壇者のお話への所感も残しておきます。