<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>AI on 怠惰技術ブログ</title>
    <link>/tags/ai/</link>
    <description>Recent content in AI on 怠惰技術ブログ</description>
    <generator>Hugo -- 0.147.7</generator>
    <language>ja</language>
    <lastBuildDate>Sat, 28 Mar 2026 10:00:00 +0900</lastBuildDate>
    <atom:link href="/tags/ai/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>AI コーディングエージェントを飼い慣らす：最強の「AGENTS.md」の書き方</title>
      <link>/posts/2026-03-28-write-agents-rules/</link>
      <pubDate>Sat, 28 Mar 2026 10:00:00 +0900</pubDate>
      <guid>/posts/2026-03-28-write-agents-rules/</guid>
      <description>&lt;h1 id=&#34;ai-コーディングエージェントを飼い慣らす最強のagentsmdの書き方&#34;&gt;AI コーディングエージェントを飼い慣らす：最強の「AGENTS.md」の書き方&lt;/h1&gt;
&lt;p&gt;近年、Gemini、Claude、Aider といった「自律型 AI コーディングエージェント」が開発現場に浸透しつつあります。彼らは指示一つでファイル構成を理解し、コードを書き、テストを実行して修正まで行います。&lt;/p&gt;
&lt;p&gt;しかし、エージェントを使い始めた多くのエンジニアが直面するのが、**「AI エージェントの暴走」**です。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;型定義を面倒くさがって &lt;code&gt;any&lt;/code&gt; を連発する&lt;/li&gt;
&lt;li&gt;プロジェクト独自のディレクトリ構造を無視して勝手に &lt;code&gt;utils/&lt;/code&gt; を作る&lt;/li&gt;
&lt;li&gt;&lt;code&gt;vitest --watch&lt;/code&gt; などの終了しないコマンドを叩いてフリーズする&lt;/li&gt;
&lt;li&gt;指示していないリファクタリングを始めて関係ないファイルを壊す&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;これらの問題を防ぎ、エージェントを「熟練のペアプロ相手」に変える魔法のファイル、それが &lt;strong&gt;&lt;code&gt;AGENTS.md&lt;/code&gt;&lt;/strong&gt; です。本記事では、AI エージェントに守らせるべきルールを定義する &lt;code&gt;AGENTS.md&lt;/code&gt; の書き方と、その設計思想を徹底解説します。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;なぜ-agentsmd-が必要なのか&#34;&gt;なぜ &lt;code&gt;AGENTS.md&lt;/code&gt; が必要なのか&lt;/h2&gt;
&lt;p&gt;AI エージェントは、人間が数年かけて培った「プロジェクトの阿吽の呼吸」を知りません。
エージェントに与えられるコンテキスト（ファイル内容や履歴）は有限であり、その中で彼らは「最も確率的に正しそうな推論」を行います。その結果、彼らはしばしば**「最も楽な道（＝技術的負債を生む道）」**を選んでしまいます。&lt;/p&gt;
&lt;p&gt;&lt;code&gt;AGENTS.md&lt;/code&gt; をプロジェクトのルートに配置する理由は、**「エージェントの推論空間に強制的な制約（ガードレール）を設けるため」**です。&lt;/p&gt;
&lt;h3 id=&#34;なぜその設計にしたか外部メモリとしての役割&#34;&gt;なぜその設計にしたか：外部メモリとしての役割&lt;/h3&gt;
&lt;p&gt;エージェントは毎回ゼロベースで思考するわけではありませんが、多くのファイルを見すぎることで逆に重要なルールを見失う（ロスト・イン・ザ・ミドル現象）ことがあります。&lt;code&gt;AGENTS.md&lt;/code&gt; という明確なルールブックを定義し、エージェントの起動時やタスク開始時に必ず読み込ませることで、思考のブレを最小限に抑えることができます。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;agentsmd-に書くべき内容の-4-つの分類&#34;&gt;&lt;code&gt;AGENTS.md&lt;/code&gt; に書くべき内容の 4 つの分類&lt;/h2&gt;
&lt;p&gt;効果的な &lt;code&gt;AGENTS.md&lt;/code&gt; は、以下の 4 つのセクションで構成するのがベストプラティスです。&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;禁止事項 (Prohibitions):&lt;/strong&gt; 致命的なエラーや環境のハングを防ぐ&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;命名規則・コーディング基準 (Standards):&lt;/strong&gt; コードの品質を一定に保つ&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;アーキテクチャ原則 (Architecture):&lt;/strong&gt; システムの整合性を維持する&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;テスト・検証方針 (Testing):&lt;/strong&gt; 修正の正しさを担保する&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;それぞれのセクションについて、具体的な記述例を見ていきましょう。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;1-禁止事項-prohibitions&#34;&gt;1. 禁止事項 (Prohibitions)&lt;/h2&gt;
&lt;p&gt;エージェントが最もやりがちな「環境破壊」を防ぐための最重要セクションです。&lt;/p&gt;
&lt;table&gt;
  &lt;thead&gt;
      &lt;tr&gt;
          &lt;th style=&#34;text-align: left&#34;&gt;ルール&lt;/th&gt;
          &lt;th style=&#34;text-align: left&#34;&gt;理由（なぜその設計にするか）&lt;/th&gt;
      &lt;/tr&gt;
  &lt;/thead&gt;
  &lt;tbody&gt;
      &lt;tr&gt;
          &lt;td style=&#34;text-align: left&#34;&gt;&lt;strong&gt;インタラクティブコマンドの禁止&lt;/strong&gt;&lt;/td&gt;
          &lt;td style=&#34;text-align: left&#34;&gt;&lt;code&gt;npm init&lt;/code&gt; や &lt;code&gt;git commit&lt;/code&gt; (メッセージ入力待ち) など、ユーザー入力を待つコマンドは CLI エージェントをフリーズさせます。&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td style=&#34;text-align: left&#34;&gt;&lt;strong&gt;Watch Mode の禁止&lt;/strong&gt;&lt;/td&gt;
          &lt;td style=&#34;text-align: left&#34;&gt;&lt;code&gt;vitest --watch&lt;/code&gt; 等はプロセスが終了しないため、エージェントが「完了」を検知できなくなります。&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td style=&#34;text-align: left&#34;&gt;&lt;strong&gt;&lt;code&gt;any&lt;/code&gt; 型の原則禁止&lt;/strong&gt;&lt;/td&gt;
          &lt;td style=&#34;text-align: left&#34;&gt;AI は型の整合性を取るのが面倒になると &lt;code&gt;any&lt;/code&gt; で逃げようとします。これは長期的な保守性を著しく低下させます。&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td style=&#34;text-align: left&#34;&gt;&lt;strong&gt;勝手な依存関係の追加禁止&lt;/strong&gt;&lt;/td&gt;
          &lt;td style=&#34;text-align: left&#34;&gt;&lt;code&gt;package.json&lt;/code&gt; を書き換えて新しいライブラリを入れる行為は、セキュリティやビルドサイズに影響するため、人間の許可を必須にします。&lt;/td&gt;
      &lt;/tr&gt;
  &lt;/tbody&gt;
&lt;/table&gt;
&lt;h3 id=&#34;実例コード&#34;&gt;実例コード&lt;/h3&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-markdown&#34; data-lang=&#34;markdown&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;## 禁止事項
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;&lt;/span&gt;&lt;span style=&#34;color:#66d9ef&#34;&gt;-&lt;/span&gt; **コマンド実行**:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#66d9ef&#34;&gt;-&lt;/span&gt; &lt;span style=&#34;color:#e6db74&#34;&gt;`vi`&lt;/span&gt;, &lt;span style=&#34;color:#e6db74&#34;&gt;`nano`&lt;/span&gt;, &lt;span style=&#34;color:#e6db74&#34;&gt;`top`&lt;/span&gt; などのインタラクティブなコマンドは実行しない。
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#66d9ef&#34;&gt;-&lt;/span&gt; &lt;span style=&#34;color:#e6db74&#34;&gt;`npm start`&lt;/span&gt;, &lt;span style=&#34;color:#e6db74&#34;&gt;`vitest --watch`&lt;/span&gt; などの終了しないプロセスは背景実行 (&lt;span style=&#34;color:#e6db74&#34;&gt;`&amp;amp;`&lt;/span&gt;) するか、単発実行モードを使用すること。
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#66d9ef&#34;&gt;-&lt;/span&gt; **TypeScript**:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#66d9ef&#34;&gt;-&lt;/span&gt; &lt;span style=&#34;color:#e6db74&#34;&gt;`any`&lt;/span&gt; 型の使用は厳禁。どうしても必要な場合はコメントで理由を明記すること。
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#66d9ef&#34;&gt;-&lt;/span&gt; **Git**:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#66d9ef&#34;&gt;-&lt;/span&gt; ユーザーの明示的な指示なしに &lt;span style=&#34;color:#e6db74&#34;&gt;`git commit`&lt;/span&gt; や &lt;span style=&#34;color:#e6db74&#34;&gt;`git push`&lt;/span&gt; を行わない。
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;hr&gt;
&lt;h2 id=&#34;2-命名規則コーディング基準-standards&#34;&gt;2. 命名規則・コーディング基準 (Standards)&lt;/h2&gt;
&lt;p&gt;プロジェクトの「見た目」と「一貫性」を守るためのルールです。ここを疎かにすると、エージェントは自分の得意なスタイル（多くの場合、学習データで最も多いスタイル）で書き始めてしまいます。&lt;/p&gt;</description>
    </item>
    <item>
      <title>GEMINI.mdでAIに開発履歴を管理させる方法</title>
      <link>/posts/2026-01-31-gemini-cli-history/</link>
      <pubDate>Sat, 31 Jan 2026 19:30:00 +0900</pubDate>
      <guid>/posts/2026-01-31-gemini-cli-history/</guid>
      <description>GEMINI.mdファイルを使ってAI（Gemini）にコーディングルールと開発履歴を管理させる手法を紹介します。AIが自分で学習・改善していくドキュメント駆動開発の実践例。</description>
    </item>
    <item>
      <title>Gemini CLIでExpo Todoアプリを爆速開発した話</title>
      <link>/posts/2026-01-31-gemini-cli-expo/</link>
      <pubDate>Sat, 31 Jan 2026 19:00:00 +0900</pubDate>
      <guid>/posts/2026-01-31-gemini-cli-expo/</guid>
      <description>Gemini CLI を使って Expo の Todo アプリを開発した体験記。GEMINI.md でルールを管理し、段階的に機能を追加していく方法を紹介します。</description>
    </item>
  </channel>
</rss>
