Go製Webフレームワーク「Popcorn Web」を作りつつ、AIエージェント向けのナレッジ中心設計手法を実践した記事。GoogleのOKF（Open Knowledge Format）を参考に、設計情報をobjective/concept/interfaceなどの型に分類しYAML中心のMarkdownで細分化して管理するスキルを自作。ソースコードではなくナレッジをSSoTとし、AIがそこから実装・フィードバックを行うワークフローを構築した。popcornweb/tinybind-go/tinygodriverの3リポジトリに分けて開発し、リポジトリ間の連携は提案書をAIに作らせて相手側ナレッジに評価させる方式を採用。あえて同じモデルを対立させることで設計を洗練させる効果があった一方、過去の決定記録は言い合いの火種になりノイズだったと述べている。
ClaudeCodeを日常的に使う中で、複数セッションの停止状況を見落としたり、作業許諾を確認せず承認してしまう癖がついた反省から、自分自身を信用しないための個人用セキュリティ監視ダッシュボードを作成した記事。
アソビューCTOが、AIによって開発コストが下がる中でエンジニアリングのボトルネックが「作れるか」から「何を検証しプロダクトに残すか」へ移動していると論じる記事。社内の座席指定チケットシステム連携事例では、担当エンジニアがAIに技術実装を任せてPdM・デザイナー・マーケ領域を主体的に担い、数年放置されていた案件を2〜3営業日でリリースした。一方、宿泊・レジャー業界の人手不足という市場背景も紹介し、AIに代替できない「顧客の本当の課題を掴む力」の重要性を強調。AIを活かす組織には承認権限の分散・自動検証・現場の一次情報を渡す仕組みと、職種の垣根を越える文化的土台が必要だと結論づけている。
GitLab 19.3では、AIエージェント型ワークロードに対する制御機能を強化。GitLab Dedicated向けAIゲートウェイでデータ所在地・分離ルールをエージェントにも適用し、GitLab Secrets Managerをリミテッド提供してCIシークレットの適用範囲を細かく設定可能にした（Kubernetes/Terraform/OpenTofu対応追加）。さらにSAST検出結果の一括誤検出判定・一括修正、自然言語でフローを生成するFlow Creatorエージェント、GitLabクレジットの利用上限機能、グループ単位のカスタムエージェント公開範囲制限も提供する。エージェントの高速化に加え、権限・コスト・データ所在地の制御を強めた点が特徴。
Linux Foundation傘下のAgentic AI Foundation（AAIF）がMCP（Model Context Protocol）の新ロードマップを発表した。今後はAIエージェント向けメッセージング機能の強化、通信方式のHTTPネイティブへの統一、AIエージェント自身のアイデンティティ管理とエンタープライズ向けセキュリティの実装、ツール呼び出し・発見の簡素化、SDKの開発者体験改善の5分野に注力する方針。
Claude Code v2.1.221（2026-08-03）以降、auto modeやbypass permissions mode有効時にRead/Edit/WriteよりBashのcat/sed等を優先させる指示がシステムプロンプトに無告知で追加されていたことをバイナリgrepで実測した記事。changelogや公式ドキュメントに記載がなく、/rewindの追跡対象外になる不具合やsedによるデータ損失などの実害もGitHub issueで報告されている。
CLIツールのデモGIF作成に、ターミナル操作をコードとして記述できるcharmbracelet製ツールVHSを使うと便利という記事。tapeファイルにキー操作とSleepを並べるだけでGIFを生成でき、Hide/Showで不要な準備部分を録画から隠せる。操作がコード化されているためAIに丸ごと作成・修正を任せられる点も利点として紹介している。
DataRobot Japanの筆者が「AIの民主化」の言い出しっぺとして、この標語を終わりにすべきと主張する記事。AutoML時代は専門家と非専門家の生産性差が1対5程度で、リスクの低い領域なら70点のモデルでも価値が出たため民主化が成立した。一方AIエージェント時代は差が1対100〜1000に開き、合格ラインは80点以上に上がったのに非専門家の初期値は30点程度に下がり、例外処理・セキュリティ・評価基盤・トークンコスト設計などソフトウェア工学の知識が必須になった。YouTube黎明期の「クリエイターと視聴者への役割分離」を補助線に、ドメイン知識は現場との会話で専門家が吸い上げれば足り、現場を開発者に仕立てる必要はないと論じる。結論として「AIの民主化」から、専門家組織（CoE）が開発とガバナンスを担い現場は使い手としてスケールする「AIの組織化」への転換を提言している。
AIエージェントを24時間稼働させる「常時ぶん回し」が礼賛される風潮に対し、コスト構造（高品質モデルはAPI課金で破綻、安価モデルは手戻りコストで破綻）と設計思想（無駄な処理を回さないのが良い設計、動的オーケストレーションの欠如）の両面から疑問を呈する記事。さらにプロダクト開発の本質的ボトルネックは「作ること」ではなく「使われること」にあり、レベルデザインやエッジケース対応、マーケティングやSEOなど人間の判断が必要な工程は自動化できないと指摘し、AIを常時稼働させる発信の多くはリリース後の泥臭い工程を省いているだけではないかと論じている。
Claude Codeのサブエージェントが43本まで増えて破綻したため、agentから「観点(lens/persona)」を切り離し、実行環境(モデル・ツール・権限)だけを持つ「器」として汎用化する設計に移行した記事。観点ファイルのパスを呼び出し側から渡す形にすることで、agent数を8本(+特化3本)まで削減し、起動時のdescription容量を7,318字から1,604字に圧縮。公式ドキュメントとの整合性も検証し、「2つ目の呼び出し元が同じ観点を欲しがるか」を人格を本文に焼き込むか外部ファイル化するかの判断基準として提示している。
AIエージェントを使った開発フローを「ループエンジニアリング」の観点で評価し直した実践記録。人間が都度承認する従来フローはAutomations項目でF評価となり、評価観点と評価基準の混同、状態遷移への人間確認ステータス欠如、承認の一律化、仕事の自律発見の欠如といった問題を指摘された。可逆性と影響範囲の2軸で人間確認の要否を仕分け、機械的な合格/停止基準を導入し、エージェントの自己申告に頼らず客観的な検証を重視する方針に転換。学びを組み込んだ開発キットを試作しAutomations評価はB相当まで改善したという内容。
テクニカルサポート業務にAIエージェントを活用してきた著者が、5ヶ月間の運用を振り返り、自動化の線引きについて考察。参照元が明確で答えが一意に決まる仕様回答は自動化を進められる一方、ログやコードから「なぜこうなったか」を組み立てて説明するテクサポ調査は、事実収集はAIに任せられても、説明の組み立てや相手のニーズに合わせた回答作成は人間の判断が必要と結論づけている。
AI駆動開発ライフサイクル(AI-DLC)を紹介する記事。AIツールを導入しても開発が速くならない原因は人間同士の意思決定・合意形成のボトルネックにあるとし、AIを単なる効率化ツールでなくチームの協力者と位置付け、Inception/Construction/Operationの3フェーズとモブワークによる上流工程改革を提案。MIXIやMonotaROの導入事例も紹介している。
Claude Codeの設定でハマりやすい事例集。fork機能が既定ONと書かれていても対話セッション限定で環境変数CLAUDE_CODE_FORK_SUBAGENT=1が必要、CLAUDE_CODE_ENABLE_TASKS=0がTodoリスト消失の原因でENABLE_TODO_TOOLS=1で復旧、AGENTS.mdはClaude Codeでは読まれず@AGENTS.mdインポートが必要、Windowsのln -sはコピーになり同期しない、spellcheckは辞書ツール別途要で日本語には不向きなど、非公式の環境変数が挙動を左右する実例を実測ベースでまとめている。