Agent

スタッフ6人体制から0人へ。年間人件費3,000万円を削減しながら、顧問先60社の経理業務を1人でこなす税理士の事例が話題になっている。その武器は Claude Code だ。 元記事: スタッフ0人で顧問先60社。税理士がClaude Codeで"AI経理"を実現した全手法 毎晩21時に60社分の自動仕訳 中核となるのは、毎晩21時に自動実行される仕訳処理だ。freee API から未処理明細を取得し、自動で勘定科目を判定して登録する。処理時間は従来の5時間から50分へと大幅に短縮された。 2段階の勘定科目判定 仕訳の精度を担保するために、2段階の判定システムが採用されている。 第1段階: キーワード辞書マッチング 14カテゴリ、100以上のキーワードで構成された辞書による高速判定。例えば: Suica → 旅費交通費 飲食店1万円以下 → 会議費 飲食店1万円超 → 交際費 第2段階: Claude API フォールバック 辞書でマッチしなかったものは Claude API が判定する。信頼度が低い場合は「人間確認」フラグが立ち、税理士がレビューする仕組みだ。 7種類の除外ルール 自動仕訳の対象外として、以下の7種類が除外される: 内容不明のデビット 借入返済 社会保険料・税金 給与 投資・資産運用 ATM出金 公共料金 給与や税金など、金額の誤りが重大な影響を及ぼす項目は自動化の対象外とし、人間が確認する。この「触ってはいけないものを明確にする」線引きが、実務での信頼性を支えている。 MCP連携で「転記ゼロ」を実現 Claude Code の MCP（Model Context Protocol）を活用し、5つのサービスと接続している: freee — 取引データの取得・仕訳登録 Gmail — リマインドメールの作成 Google Calendar — スケジュール確認 Notion — 議事録からアジェンダ自動生成 Slack — TODO管理 これにより、サービス間の手作業による転記がゼロになった。 CLAUDE.md とスキルによる業務の「言語化」 技術的に重要なのは、CLAUDE.md に業務の判断基準をすべて言語化して記述している点だ。仕訳分類ルール、税区分の処理方法、セキュリティポリシー、出力先ルールなどが定義されている。 ...

Agentic Coding（AIエージェントによるコーディング）が普及する中、AIに渡すドキュメントをどこに配置すべきかという問題が注目されています。古川陽介氏（@yosuke_furukawa）のポストで紹介されていた記事「Your Docs Directory Is Doomed」（Yagmin）の内容をもとに、この問題を考えます。 /docs ディレクトリの進化と限界 Agentic Coding を始めると、多くのプロジェクトで以下のようなドキュメントが増えていきます: まず CLAUDE.md や AGENTS.md のような設定ファイルを作成 ARCHITECTURE.md でシステム全体の構造を記述 機能仕様やデザインドキュメントを /docs フォルダにまとめ始める この流れ自体は自然ですが、記事では /docs ディレクトリへの集約には根本的な問題があると指摘しています。 /docs ディレクトリの問題点 1. 発見可能性（Discoverability） LLM はどのドキュメントをいつ読むべきかを自律的に判断する必要があります。/docs に大量のファイルがある場合、LLM が適切なドキュメントを見つけられる保証はありません。計画フェーズで必要なドキュメントと、コード生成フェーズで必要なドキュメントは異なりますが、それを正しく参照できるでしょうか。 2. ドキュメントの腐敗（Documentation Rot） コードは頻繁に変更されますが、対応するドキュメントの更新は忘れがちです。小さな不整合が積み重なり、LLM が参照するコンテキストの品質が徐々に劣化していきます。さらに厄介なのは、ドキュメントが間違っていることに気づくための仕組み（observability）がないことです。 3. 構造の欠如 ドキュメント間の階層関係や依存関係が明示されていないため、LLM がドキュメント群をナビゲートする明確な方法がありません。各自が自分のスタイルで書くため、LLM にとって情報の探索がしにくい構造になります。 4. 変更速度の不一致（Velocity Mismatch） ドキュメントの種類によって変更頻度が異なります。アーキテクチャの概要はめったに変わりませんが、API仕様やコンポーネントの詳細は頻繁に更新されます。一つのディレクトリにすべてをまとめると、この違いが管理を困難にします。 コロケーション（Colocation）というアプローチ 古川氏がツイートで触れているように、一つの解決策はコロケーション — ドキュメントをコードの近くに直接配置する方法です。 src/ auth/ README.md # 認証モジュールの説明 auth.ts auth.test.ts api/ README.md # APIモジュールの説明 routes.ts middleware.ts このアプローチの利点: 発見可能性の向上: 関連コードと同じディレクトリにあるため、LLM が自然に参照できる 更新の同期: コードを変更する際にドキュメントも目に入るため、更新忘れが減る スコープの明確化: 各ドキュメントが担当する範囲が明確 Agentic Coding でのドキュメント管理の方向性 「Your Docs Directory Is Doomed」の記事は、従来のドキュメント管理は「1985年からの解決策」に過ぎないと指摘しています。Agentic Coding 時代には、以下の要素が重要になります: ...

動画編集者のカズマル氏（株式会社ブイスト）が、300日以上かけて50種類以上のAIツールに500万円以上を課金して検証した「AI動画編集 自動化のカラクリ」が話題になっている。AIによる自動カットと自動テロップで、動画編集のワークフローがどう変わるのかを整理する。 AI動画編集が解決する2つの課題 動画編集で最も時間がかかる作業は、大きく2つに分けられる： カット編集 — 無音部分、言い淀み、NGテイクの除去 テロップ作成 — 字幕・キャプションの生成と配置 従来これらは手作業で行うしかなく、30分のインタビュー動画であればテロップ作成だけで2時間以上かかることも珍しくなかった。AIツールの登場により、これらの作業が大幅に自動化されつつある。 自動カットの仕組み AIによる自動カットは、主に音声波形解析と無音区間検出で実現されている。 代表的なアプローチ 無音区間の自動検出・削除: 音声波形から無音部分を特定し、ワンクリックで除去 フィラーワード検出: 「えーと」「あのー」など不要な言い淀みを音声認識で検出して除去 ジャンプカット生成: 不要な間を詰めた際の映像の不自然さを、自動ズーム・パンで軽減 実務での注意点 感度設定が重要で、高すぎると必要な「間」までカットされてしまう。プレビューで確認しながらの調整が必須だ。 自動テロップの仕組み 音声認識（STT: Speech-to-Text）技術を使い、動画内の音声を自動で文字起こしして字幕化する。 最新のAI文字起こし精度 2026年現在、日本語の音声認識精度は飛躍的に向上しており、実用レベルに達している。多くのツールが100言語以上に対応し、翻訳字幕の自動生成も可能になっている。 テロップ作成の効率化 手動でテロップを作成する場合と比較して、最大90%以上の時間短縮が見込める。30分のインタビュー動画であれば、通常2時間以上かかるテロップ作成が数分〜15分程度で完了する。 主要なAI動画編集ツール Vrew（ブリュー） 韓国Voyager X社が開発したオールインワンAIビデオエディター。 音声認識ベースの編集: 動画の音声を自動で文字起こしし、テキストベースで編集可能 無音区間の自動削除: ワンクリックで無音部分を検出・削除 テキスト編集＝映像編集: 文字起こしテキストの不要部分を削除すると、対応する映像も自動カット 無料プランあり Adobe Premiere Pro プロ向け動画編集ソフトにもAI機能が搭載されている。 シーン編集検出: AIが自動的にシーン境界を検出してカット 自動文字起こし: 音声からキャプションを自動生成 カラーマッチ: 異なるシーンの色合いをAIで自動調整 OpusClip 長尺動画からショート動画を自動生成するクラウドサービス。 見どころの自動抽出: AIが重要なセグメントを検出してダイジェスト動画を生成 自動字幕生成: 多言語対応・翻訳機能付き ノイズ除去: AI音声エンハンス機能 PowerDirector CyberLink社のAI搭載動画編集ソフト。 AI音声読み上げ: テキストから音声を自動生成 AI背景除去・自動顔ぼかし: 映像加工の自動化 AIノイズ除去: 音声品質の向上 500万円の課金検証から見えるもの カズマル氏のように大量のツールを実際に業務で検証することで見えてくるのは、単一のツールで完結するケースは少ないということだ。実務では複数のツールを組み合わせたワークフローが必要になる。 一般的なAI動画編集ワークフロー 素材撮影 → AIで無音カット → AI文字起こし → テロップ調整 → 最終編集 （Vrew等） （Vrew/Premiere） （手動微調整） （Premiere等） 重要なのは、AIは「完全自動化」ではなく「大幅な時短」を実現するツールだという点だ。最終的な品質チェックと微調整は人間の判断が必要になる。 ...

テックコミュニケーション・コンサルタントのJim Prosser氏が、Claude Codeを使って36時間で個人用AIアシスタントシステムを構築した。「My chief of staff, Claude Code」と題されたこの取り組みは、非エンジニアがClaude Codeのサブエージェント機能を活用して日常業務を自動化した実践例として注目を集めている。 システムの全体像 Prosser氏が構築したのは、毎朝起床前に自動で業務の下準備を完了させるシステムだ。常時稼働のMac Studio上で2つの自動プロセスが夜間に実行され、朝6:15までに処理が完了する。 主な機能: メール自動トリアージ — 受信メールからアクション可能な項目を特定し、Todoistのタスクと重複チェック カレンダー管理 — Google Maps APIを使った実際の移動時間計算を含むスケジュール最適化 6つの並列AIエージェント — Claude Codeのサブエージェント機能で独立したワーカーを同時実行 「AM Sweep」ボタンの仕組み Stream Deckの物理ボタンを押すと、6つの専門エージェントが並列で起動する: メール下書き作成（送信はしない、レビュー用の下書きのみ） Obsidianのクライアントファイル更新 ミーティングのスケジュール調整 見込み客やトピックのバックグラウンドリサーチ タスクの分類とコンテキスト収集 各エージェントは独自のコンテキストウィンドウとスコープされたツールアクセスを持ち、互いに干渉せずに動作する。 タスク4色分類フレームワーク Prosser氏は「dispatch, prep, yours, skip」の4段階でタスクを分類する: 色 分類 内容 🟢 緑 Dispatch AIが完全に処理 🟡 黄 Prep AIが80%完了、人間が仕上げ 🔴 赤 Yours 人間の判断が必要としてフラグ ⚪ 灰 Skip 理由付きで延期 重要なのは、判断に迷う場合は「Dispatch」ではなく「Prep」にデフォルトする設計だ。AIが勝手に完了させるのではなく、人間が最終判断する余地を常に残している。 人間とAIの境界線 このシステムの設計で最も重要な原則は「AIにやらせないことを決める」ことだ: メールは絶対に送信しない — 下書きのみ作成し、人間がレビューして送信 戦略的決定は人間が行う — 価格交渉、関係性に配慮が必要なコミュニケーションはAI対象外 不確実な場合はPrepにデフォルト — 自動処理より人間の関与を優先 Time Block機能 残タスクをカレンダーイベントに変換する機能も備えている: ...

Andrej Karpathy が2026年3月に公開した autoresearch は、AIエージェントにLLMのトレーニングを丸投げするツールだ。GPU1台・一晩放置するだけで、エージェントが自律的にコード修正→実験→評価を繰り返し、人間の研究者なしで性能を改善していく。 実際に Karpathy 自身が約700回の実験を実行したところ、GPT-2の学習時間が2.02時間→1.80時間へ11%短縮された。さらに別の開発者は、8時間・37実験で0.8Bモデルが従来の1.6Bモデルを19%上回るスコアを叩き出している。 autoresearch の仕組み autoresearch はわずか630行のPythonで構成されており、3つのコアファイルで動作する。 3つのコンポーネント ファイル 役割 編集者 program.md エージェントへの指示書（戦略・ルール・評価基準） 人間 prepare.py データ準備・トークナイザー・評価関数（固定） 変更禁止 train.py モデル・オプティマイザ・学習ループ AIエージェント エージェントループ エージェントは以下のサイクルを自動で繰り返す: program.md を読んで戦略を把握 train.py を修正（アーキテクチャ変更、ハイパーパラメータ調整など） 5分間の固定時間でトレーニングを実行 val_bpb（検証ビット/バイト）が改善したか確認 改善 → 変更を保持、悪化 → 変更を破棄 1に戻る 5分の固定時間予算により、1時間あたり約12実験、一晩（8時間）で約100実験が可能になる。 実験結果 Karpathy 自身の実験 Karpathy は自身の nanochat（GPT-2トレーニング環境）に autoresearch を適用: 約700回の実験を2日間で実行 約20個の実質的な改善を発見 GPT-2到達時間: 2.02時間 → 1.80時間（11%短縮） 発見された改善の例: バッチサイズの半減（5分以内のステップ数増加） モデル深度の調整（depth 9への最適化） スライディングウィンドウ比率のチューニング コミュニティの成果 GitHub Discussions で報告された改善: Discussion #32: val_bpb を 0.9979 → 0.9773 に改善（89実験、H100 80GB） Discussion #43: val_bpb を 0.9979 → 0.9697 に改善（126実験、H100 80GB） Tobi のケース: 0.8Bモデルが従来の1.6Bモデルを 19%上回るスコア（37実験、8時間） 使用されるLLM autoresearch のエージェントとして動作するLLM自体は外部モデルを使用する。Karpathy のテストでは Claude や GPT 系モデルが使われている。 ...

AIエージェントが単独で動く時代から、複数のエージェントが協調して動く時代へ移行しつつある。エージェント間の通信を設計するとき、「会話（何を話すか）」と「transport（どう届けるか）」を分離する考え方が重要になっている。本記事では、2026年に整備が進むエージェント間通信プロトコルの全体像と、Relay基盤のアーキテクチャを整理する。 なぜ「会話」と「transport」を分離するのか AIエージェント同士が会話する際、2つの関心事が混在しがちだ: 会話層: タスクの依頼、進捗報告、結果の返却といった「意味のあるやりとり」 transport層: HTTP、gRPC、WebSocket、SSE といった「届ける仕組み」 これらを密結合にすると、transport を変更するたびに会話ロジックを書き直す必要が生じる。たとえば、開発時は HTTP で通信していたエージェントを、本番では gRPC に切り替えたいケースや、ローカルの関数呼び出しからリモートの API 呼び出しに切り替えたいケースがある。 分離することで、エージェントのビジネスロジック（会話）は transport に依存せず、transport の差し替えが容易になる。 2026年のエージェント間通信プロトコル 現在、エージェント通信の標準化が急速に進んでいる。主要なプロトコルは以下の通り。 MCP（Model Context Protocol） Anthropic が策定したプロトコルで、エージェントと外部ツール/リソースの接続を標準化する。API、ファイルシステム、データベースへのアクセスを統一的なインターフェースで提供する。 役割: ツール・コンテキスト層 transport: RESTful サーバー経由の構造化データ交換 エージェント → MCP サーバー → 外部ツール（DB, API, ファイル） A2A（Agent-to-Agent Protocol） Google が主導し、50社以上のパートナーが参加するオープン標準。エージェント同士のピアツーピア通信とタスク委譲を実現する。 役割: エージェント間通信層 transport: HTTPS 上の JSON-RPC 2.0 + SSE（ストリーミング） 通信モデル: クライアントエージェント → リモートエージェント クライアントエージェント ──JSON-RPC──→ リモートエージェント ←──SSE──── A2A の特徴は、エージェントの内部メモリ、ツール、ロジックを共有せずに協調できる点。発見（Discovery）→ 認可（Authorization）→ 通信（Communication）の3段階で動作する。 ACP（Agent Communication Platform） REST ベースの通信とエージェントレジストリを組み合わせたプラットフォーム。 役割: レジストリ駆動の通信基盤 transport: REST インターフェース 特徴: ステートフルなメッセージルーティングでコンテキストを保持 ANP（Agent Network Protocol） インターネット規模のエージェント協調を想定したプロトコル。 ...

Anthropic が Claude Code にリサーチプレビューとして「Auto Mode」を導入しました。claude --permission-mode auto で起動すると、ツール使用の許可判断を Claude 自身が行い、開発者の手動承認なしで長時間の連続作業が可能になります。 Auto Mode とは 従来の Claude Code では、ファイルの書き込みやシェルコマンドの実行のたびに許可プロンプトが表示されていました。これは安全性の面では重要ですが、長時間のタスクでは開発フローが頻繁に中断される原因になっていました。 Auto Mode はこの問題に対処するもので、各操作について Claude 自身がリスクを判断し、安全と判断した操作は自動で承認します。 使い方 起動時にフラグを指定します: 1 claude --permission-mode auto または、セッション中に Shift+Tab で許可モードを切り替えることもできます。 既存の許可モードとの比較 Claude Code には複数の許可モードがあります: モード 動作 Normal 操作ごとに許可を求める（デフォルト） Auto-accept edit ファイル編集は自動承認、シェルコマンドは確認 Auto Mode Claude がリスク判断して自動承認（新機能） Plan 読み取り専用、変更は一切行わない Auto Mode は --dangerously-skip-permissions のような全許可フラグとは異なり、Claude がリスク分類を行った上で判断するため、安全性と利便性のバランスを取ったアプローチです。 セキュリティ上の注意点 Auto Mode は万能ではありません。Anthropic は以下の点を注意喚起しています: 隔離環境での使用を推奨: 本番環境の認証情報やライブ API へのアクセスがあるマシンでは使わない プロンプトインジェクション対策: ファイルやコマンド出力内の悪意ある指示から保護する機能を搭載 トークン使用量の増加: リスク判断のオーバーヘッドにより、若干のコスト・レイテンシ増加がある 組織での管理 IT 管理者は Auto Mode を制限することもできます: ...

Claude Code の Skills 機能を使って、過去のプロンプト入力履歴をスキャンし、利用者が「何を分かっていて、何を分かっていないか」を可視化する仕組みが紹介されていました。プロンプトを通じた新人教育の可能性を探ります。 アイデアの概要 @tokoroten氏のポストで紹介されたアプローチは以下の通りです: Claude Code の Skills を利用して、過去のプロンプト入力履歴をスキャンする その履歴から、利用者が何を理解していて、何を理解していないかを分析・出力する 結果として、どの技術分野の理解が甘いかが可視化される これにより、プロンプトを通じた新人教育が可能になる Claude Code Skills とは Claude Code の Skills は、再利用可能なプロンプトテンプレートをプロジェクト内に定義できる機能です。.claude/skills/ ディレクトリにスキル定義を配置することで、/スキル名 のようなスラッシュコマンドとして呼び出せます。 .claude/ skills/ analyze-prompts/ skill.md # スキルの定義・プロンプト スキルには以下のような特徴があります: プロジェクト固有のワークフローを定義できる 引数を受け取ることが可能 複数のツール呼び出しを組み合わせた複雑な処理を自動化できる プロンプト履歴から理解度を分析する仕組み このアプローチの面白いところは、プロンプト（質問）の内容自体が「その人が何を知らないか」の強力なシグナルになるという点です。 分析の観点 質問の頻度: 特定の技術領域について繰り返し質問しているなら、その分野の理解が浅い可能性が高い 質問の深さ: 基本的な概念を聞いているのか、応用的な質問をしているのかで理解度が測れる 自己解決率: 同じトピックの質問が減っていれば、学習が進んでいると判断できる 教育への応用 従来の新人教育では、メンターが1対1でレビューしたり、定期的な面談で理解度を確認したりする必要がありました。このアプローチでは: 受動的な観察: 普段の業務でのプロンプト利用を分析するだけで、能動的なヒアリングが不要 定量的な評価: どの分野にどれだけ質問しているかを数値化できる 継続的なトラッキング: 時系列での成長を追跡できる 実現に向けた考慮点 このような仕組みを導入する際には、いくつかの点を考慮する必要があります。 プライバシーへの配慮 プロンプト履歴には業務上の機密情報が含まれる可能性があるため、分析対象の範囲や匿名化の方法を検討する必要があります。 分析精度の担保 単純なキーワードマッチだけでは正確な理解度評価は難しく、文脈を考慮した分析が求められます。Claude Code 自体の言語理解能力を活かすことで、より精度の高い分析が可能になるでしょう。 フィードバックループの構築 分析結果を本人にフィードバックし、推奨学習リソースを提示するところまで自動化できれば、より実用的な教育ツールになります。 まとめ Claude Code の Skills を活用したプロンプト履歴分析は、AI ツールの利用ログそのものを教育データとして活用するという発想です。新人が日常的に AI に質問する行為自体が、自然と学習進捗の記録になるというのは、AI 時代ならではの教育アプローチと言えます。

LLMベースのコーディングエージェント（Claude Code、Cursor など）は、セッションが変わるたびにプロジェクトの規約や過去のミスを忘れてしまう。小さなプロトタイプなら問題にならないが、10万行を超える大規模コードベースでは「毎回同じ説明をする」「直したはずのバグパターンが再発する」といったコストが無視できなくなる。 2026年2月に公開された論文 Codified Context: Infrastructure for AI Agents in a Complex Codebase（Aristidis Vasilopoulos）は、この問題に対して 3層のメモリインフラストラクチャ を提案し、108,000行のC#分散システムを283セッションかけて構築した実践データとともに検証している。 問題：セッション間で失われる記憶 LLMエージェントは各セッションの開始時にコンテキストがリセットされる。.cursorrules や CLAUDE.md のような単一ファイルでプロジェクト規約を伝える方法は小規模なら有効だが、10万行規模のシステムでは単一プロンプトに収まりきらない。 結果として起きる典型的な問題: 命名規則やアーキテクチャパターンの逸脱 過去に修正した失敗パターンの再発 サブシステム間の整合性の欠如 提案手法：3層の Codified Context 論文では、プロジェクト知識を 負荷分散インフラストラクチャ として扱う3層アーキテクチャを提案している。 Tier 1: Hot-Memory Constitution（約660行） 常にセッションにロードされるMarkdownファイル。以下を含む: コード品質基準・命名規則 ビルドコマンド アーキテクチャパターンの要約 よくある操作のチェックリスト 既知の失敗モード（過去のバグパターン） オーケストレーション用トリガーテーブル トリガーテーブルは「どのファイルを変更したら、どの専門エージェントを呼ぶか」を定義する: ファイル変更 割り当てエージェント Network, sync network-protocol-designer Coordinates, camera coordinate-wizard UI配信 ui-sync-specialist Tier 2: Specialized Agents（19エージェント、約9,300行） タスクに応じて呼び出される専門エージェント群。2つのクラスに分かれる: 高能力エージェント（8個、平均711行）: ネットワークプロトコル設計、アーキテクチャ検証、デバッグなど 標準能力エージェント（11個、平均327行）: 特定タスクにフォーカス 各エージェント仕様の 50%以上がプロジェクト固有のドメイン知識 で構成されている。コード例、数式、失敗モードなど、そのプロジェクトでしか使えない具体的な情報が埋め込まれている点が特徴。 Tier 3: Cold-Memory Knowledge Base（34文書、約16,250行） サブシステムごとの詳細仕様をMarkdownで記述し、MCP（Model Context Protocol）検索サーバー経由でオンデマンド参照する: ...

ChatGPTやClaude、Perplexityなどの AI 検索エンジンに自社サイトを見つけてもらうための最適化ツール「geo-seo-claude」がオープンソースで公開されている。従来の SEO に加えて、AI が引用・参照しやすいコンテンツ構造を自動分析・提案してくれる Claude Code 用スキルだ。 GEO（Generative Engine Optimization）とは 従来の SEO が Google などの検索エンジンでの上位表示を目指すのに対し、GEO は AI 検索エンジン（ChatGPT、Claude、Perplexity、Gemini、Google AI Overviews）での「引用されやすさ」を最適化する考え方だ。 AI がウェブ上の情報を参照して回答を生成する際、どのサイトが引用されるかは以下のような要素に左右される： コンテンツの構造化の度合い AI クローラーへのアクセス許可（robots.txt） ブランドの権威性（各プラットフォームでの言及） スキーママークアップの品質 geo-seo-claude の主な機能 引用可能性スコアリング（Citability Scoring） コンテンツが AI に引用されやすい構造になっているかを評価する。134〜167語の最適な段落長、明確な見出し構造、事実ベースの記述かどうかなどをチェックする。 AI クローラー分析 robots.txt を解析し、14以上の AI ボット（GPTBot、ClaudeBot、PerplexityBot など）へのアクセス許可状況を確認する。ブロックしているボットがあれば、許可すべきかの推奨事項を提示する。 ブランド言及スキャン YouTube、Reddit、Wikipedia、LinkedIn など7つ以上のプラットフォームでのブランド言及を検出する。AI は複数ソースでの言及が多いサイトをより信頼性が高いと判断する傾向がある。 プラットフォーム別最適化 ChatGPT、Perplexity、Google AI Overviews それぞれの特性に合わせた最適化提案を行う。各 AI 検索エンジンがコンテンツを処理する方法は異なるため、プラットフォームごとのカスタマイズが重要になる。 llms.txt 生成 AI クローラーがサイト構造を理解しやすくするための新興標準ファイル llms.txt を自動生成する。Answer.AI の Jeremy Howard が提案した規格で、robots.txt の AI 版のような位置づけを目指している（現時点ではまだ提案段階）。 PDF レポート生成 スコアゲージ、棒グラフ、カラーコード付きテーブルなど、視覚的にわかりやすいプロフェッショナルな監査レポートを PDF 形式で出力できる。 ...