関連リンク GitHub Agentic Workflows are now in technical preview GitHubは、AIエージェントを活用してリポジトリのタスクを自動化する新機能「GitHub Agentic Workflows」の技術プレビューを開始しました。これまでエンジニアが苦労して記述していた複雑なYAMLファイルの代わりに、Markdown形式の自然言語（英語などの文章）で自動化のゴールを記述できるのが最大の特徴です。 ■ 概要 GitHub Agentic Workflowsは、GitHub Actionsの中でAIエージェントを動かす仕組みです。開発者は .github/workflows/ ディレクトリにMarkdownファイルを配置し、「Issueの内容を分類してラベルを貼る」「CIが失敗した原因を分析する」「ドキュメントを最新の状態に保つ」といった目的を自然言語で記述します。これを専用のCLIツール（gh aw）でコンパイルすることで、標準的なGitHub Actionsとして実行可能な形式に変換されます。 ■ 主な特徴とメリット自然言語によるワークフロー定義： YAMLの構文を覚える必要がなく、AIに対して「何をしたいか」を伝えるだけで、AIエージェントが具体的な手順を判断して実行します。セキュリティを重視した設計：新人エンジニアでも安心して利用できるよう、デフォルトでは「読み取り専用（Read-only）」権限で動作します。また、サンドボックス環境での実行、ネットワークの隔離、依存関係の固定（SHA-pinned）など、安全性が徹底されています。書き込み操作が必要な場合は、事前に承認された「安全な出力（safe outputs）」を通じて行われます。高度なインテグレーション： GitHub Copilot CLIや他のコーディングエージェントと連携可能です。また、MCP（Model Context Protocol）サーバーを介して、リポジトリ、Issue、プルリクエスト、さらにはブラウザ操作やWeb検索といった外部ツールとも深く統合できます。オープンソース：本機能のコードはMITライセンスでGitHub上に公開されており、コミュニティによる貢献も歓迎されています。 ■ 期待される活用例・Issueの自動トリアージ（優先度付けや担当者割り当て）・プルリクエストの一次レビューや、CI失敗時のルート原因調査・リポジトリ内のドキュメントメンテナンスやテストカバレッジの向上・チームの士気を高めるような、ちょっとした自動化アクション ■ 使い方と制約現在は技術プレビュー段階であり、利用には gh aw CLI拡張機能のインストールが必要です。AIエージェントが自律的に動くため、予期せぬ挙動を防ぐためのサンドボックス制限や権限管理といった制約が設けられていますが、これらは開発者が意図しない破壊的な操作を行わないための「ガードレール」として機能します。この機能により、定型的なリポジトリ管理業務をAIに任せ、エンジニアはよりクリエイティブな開発に集中できるようになります。開発プロセスの自動化が、プログラミングそのものと同じくらい直感的になる未来に向けた大きな一歩と言えるでしょう。引用元: https://github.blog/changelog/2026-02-13-github-agentic-workflows-are-now-in-technical-preview/ AGENTS.mdを自動で育てる仕組みを作った最近のエンジニアリングにおいて、Claude CodeやCursorといった「Coding Agent（AIコーディングアシスタント）」の活用は不可欠になりつつあります。これらのAIにプロジェクト固有のルールやコマンドを伝えるための設定ファイルが「AGENTS.md（またはCLAUDE.md）」です。本記事では、このファイルを自動生成し、かつ「腐らせない」ための仕組みについて解説されています。 1. なぜAGENTS.mdの自動化が必要なのか新しいリポジトリを作るたびに、ビルドコマンドやコード規約を書き出すのは手間がかかります。また、プロジェクトが進むにつれて情報が古くなると、AIが誤った指示に従ってしまう「コンテキストの汚染」が発生します。理想は、プロジェクトの開始時に自動で足場が作られ、コードの成長に合わせて自然に中身が更新されていく状態です。 2. AGENTS.mdを書く際の重要な考え方新人エンジニアが特に意識すべき点は、「指示は少なければ少ないほど良い」という原則です。指示量の上限（バジェット）: AIが確実に従える指示には限界があります。AGENTS.mdに書く指示は「20〜30行」を目安に絞り込むべきです。書くべきこと: コードから推測できない固有の判断基準、非自明なコマンド、ドメイン用語など。書かないこと: リンターで解決できるコードスタイル、ディレクトリ構造（AIが自分で見ればわかること）、汎用的なプログラミング知識。生きたドキュメント: 古くなった指示は即座に消すか、最新の状態に更新し続ける必要があります。 3. 「育てる」ための仕組み：agents-md-generator 筆者が開発した「agents-md-generator」は、以下の工夫によってAGENTS.mdの運用を支えます。自動生成の仕組み: gitの init.templateDir と post-checkout フックを利用します。これにより、空のリポジトリを git clone した瞬間に、テンプレートとなるAGENTS.mdが自動で配置されます。自己保護機能: AI自身がAGENTS.mdを整理する際、重要なルールまで消してしまわないよう、HTMLコメント（）を使って「このセクションは消さないこと」といった指示を埋め込んでいます。メンテナンスのリマインド: テンプレート内には「プレースホルダーを埋めたら消すこと」「バジェットを守ること」といったメンテナンスノートが含まれており、AIと人間が協力してファイルをスリムに保つよう促します。結論 AIエージェントを使いこなす鍵は、AIに与える「指示の鮮度と密度」を保つことにあります。今回紹介された仕組みを導入することで、ドキュメント管理の負担を減らしつつ、常にAIのパフォーマンスを最大限に引き出す開発環境を構築できます。新人エンジニアの方も、まずは「AIへの指示は最小限にする」という意識から始めてみると、よりスムーズなAIとの共作が可能になるでしょう。引用元: https://nyosegawa.github.io/posts/agents-md-generator/ How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt AI（生成AIやAIエージェント）が普及する現代の開発において、エンジニアが向き合うべき課題は「技術負債」から「認知的負債（Cognitive Debt）」へと変化しています。本記事では、この新しい概念がエンジニアの生産性にどう影響するかを解説しています。まず「認知的負債」とは、開発スピードを優先した結果、そのツケがコードではなく「エンジニアの脳内」に蓄積される状態を指します。これまでの開発では、乱雑なコードや設計ミスといった「技術負債」が主な問題でした。しかし、AIが生成するコードは、一見すると綺麗で理解しやすいものも多いです。問題なのは、人間側が「そのプログラムが何を目的とし、どう動いているのか」という全体像（メンタルモデル）を理解するプロセスを飛ばしてしまうことにあります。記事では、ある学生チームのエピソードが紹介されています。彼らは開発が進むにつれて、簡単な変更でも予期せぬバグを引き起こすようになり、開発が停滞してしまいました。当初、彼らはコードが汚いせい（技術負債）だと考えていましたが、実際には「なぜこの設計にしたのか」「システムがどう連携しているのか」を誰も説明できなくなっていたのです。つまり、システムに対する「共通理解」が崩壊したことで、認知的負債が技術負債よりも早く蓄積し、チームを麻痺させてしまいました。これは、AIに頼り切ったスピーディーな開発（いわゆる「バイブス駆動開発」）でも同様のことが起こります。AIにプロンプトを投げて機能を次々と追加し、中身を深く理解しないまま進めると、開発者は自分のプロジェクトの中で迷子になります。自分の頭の中にシステムを推論するための材料がなくなるため、次に何を作るべきか、どう修正すべきかの確信が持てなくなるのです。新人エンジニアへのアドバイスとして、AIは強力な武器ですが、ただコードを出力させるだけでは不十分です。コードが「動く」ことと、仕組みを「理解している」ことは別物です。AI時代のエンジニアリングにおいて真に価値があるのは、AIが書いたコードを読み解き、常に自分の頭の中に「システムの地図」を更新し続ける能力です。スピードに飲まれず、なぜそのコードが必要なのかという「設計の意図」を意識的に掴み取ることが、長期的な成長とプロジェクトの成功に繋がります。引用元: https://simonwillison.net/2026/Feb/15/cognitive-debt/ Grokに「洗車機まで徒歩か運転して行くべきか」を尋ねると一気に頭がパッパラパーになって凄いことになってしまった AIに「40m先の洗車機まで徒歩と車のどちらで行くべきか」と問うと、Grok等の最新LLMが「近いから徒歩」と珍回答する現象が話題です。洗車には車が必要という物理的な前提を無視し、距離の数値のみで判断してしまうAIの「記号接地問題」や推論の癖を学べる好例です。一部の推論特化モデル以外はこの「意図」の理解に失敗しており、新人エンジニアがLLMの限界と性質を楽しく理解するのに最適な内容となっています。引用元: https://togetter.com/li/2663951 お便り投稿フォーム VOICEVOX:春日部つむぎ

Ask this episode

“What did the council decide on item 42?” — answered with the speaker and the moment.

Transcript

Related