AIエージェントの安全性は小さなソフトウェアから始まる

Matt Sephtonは2026年4月、あえてばかばかしい制約を掲げて Fits on a Floppy を公開しました。役に立つソフトウェアは、標準的な3.5インチフロッピーディスクの容量である1.44 MBに収めることを目指すべきだ、という制約です。¹

重要なのはサイズ制限そのものより、その背後にある姿勢です。Sephtonは、高速なダウンロード、即時起動、少ないメモリ使用量、低いCPU負荷、ネイティブコード、古いシステムへの対応、そして1つのことをうまく行うツールを支持しています。¹ 素直に読めば、小さなソフトウェアはユーザーを尊重するという話です。エージェント時代の読み方では、さらに一歩進みます。小さなソフトウェアは、AIコーディングエージェントがミスを隠せる場所を減らします。

AIエージェントの安全性は小さなソフトウェアから始まります。小さく、検査しやすいシステムは、エージェントが誤解し、変更し、権限を使い、テストし損ねる余地を狭めるからです。 サンドボックスや権限確認のプロンプトは、いまも重要です。小さなソフトウェアは、安全の境界をもっと上流へ、つまり成果物そのものの形へ移します。

要約

コーディングエージェントが最もよく機能するのは、コンテキストが劣化する前に、関連ファイルを読み、必要なチェックを実行し、関連する差分を説明できるときです。AnthropicのClaude Codeガイドでは、コンテキストはすぐに埋まり、埋まるほど性能が落ちると説明されています。同じガイドは、検証を最も価値のある実践だと位置づけ、CLIツールをコンテキスト効率の高いインターフェースとして説明しています。² OpenAIのローカルシェルに関するドキュメントは、シェルコマンドを実行するエージェントには、実行前のサンドボックス化、または厳格な許可リストと拒否リストが必要だと警告しています。³

小さなソフトウェアは、そうした制御を置き換えるものではありません。適用しやすくするものです。小さなツールなら、権限を与えるコマンドは少なく、検査するファイルも少なく、信頼しなければならない依存関係も少なく、実行するテストも少なくなります。誤った前提が隠れられる分岐も減ります。古いUnixの教訓は、時代遅れになっていません。McIlroyは「1つのことを行う」という考え方を初期のサイズ制約にさかのぼって説明し、そのうえで、テキストストリームがプログラムと人間の両方にとって有用な汎用インターフェースになった理由を語っています。⁴ エージェントシステムが同じパターンを再発見するのは、エージェントにも検査しやすく、組み合わせやすい接点が必要だからです。

重要なポイント

エージェントを作る人へ： - 広いAPIや大きなツールスキーマを追加する前に、明示的な入力、明示的な出力、プレーンなファイル成果物を持つ小さなツールを優先しましょう。 - ファイルパス、差分、ログ、テストを安全性の接点として扱います。エージェントも、レビュアーも、自動化も、それらを確認できます。

ソフトウェアチームへ： - 小さなソフトウェアはレビューコストを下げます。400行のツールとそのテストなら、レビュアーは一度で理解できます。広がりすぎたフレームワークは、本来証拠があるべき場所で信頼を要求します。 - 権限の範囲は、実際の操作の近くに置きます。小さなコマンドなら、読み取り専用で実行する、1つのディレクトリだけに書き込む、ネットワークアクセスを禁止するといった制限ができます。汎用コマンドはたいてい、タスクに必要な範囲を超える権限を求めます。

プロダクトリーダーへ： - 小さなソフトウェアは懐古趣味ではありません。機械が過剰なコードを過剰な速さで生み出せる世界のための統治パターンです。 - 基準は「エージェントが作れるか」から、「チームが検証し、所有し、ロールバックできるか」へ移るべきです。

小さなソフトウェアが再び重要になった理由

ソフトウェアの肥大化は、かつてユーザー体験の問題に見えていました。遅いダウンロード、重いメモリ使用量、起動の遅さ、バッテリー消耗、置き去りにされる古いデバイス。Fits on a Floppy は、意図的に物理的な基準を使ってその批判を見える形にしています。1.44 MBのバッジは、節度をユーザーにも理解できるテストへ変えます。¹

AIコーディングエージェントは、節度が重要になる理由を変えます。機械は、人間が読み切れる速度を超えてファイルを作れます。周囲のシステムが量を進捗として受け入れると、その速さは品質を弱めます。4つの新しい依存関係を伴う2,000行の機能は、作業ログ上では見栄えがよくても、プロダクト価値を増やす以上に欠陥の表面を広げているかもしれません。

小さなソフトウェアは、エージェントにはより難しい目標を、レビュアーにはよりよい対象を与えます。プロンプトでは、1つの実行ファイル、1つのデータ形式、1つのテストファイル、1つのロールバック経路を求められます。結果として、自由度は少なくなります。モデルはそれでも間違えます。しかし、その間違いが身を隠せる余地は小さくなります。

Niklaus Wirthは、コーディングエージェントがワークフローに入るずっと前の1995年に、A Plea for Lean Software という論文を発表しました。⁵ その題名がいまも響くのは、根本的な失敗が残っているからです。チームは難しいデザイン判断を避けるために、ハードウェア、依存関係、抽象レイヤーを浪費します。エージェントはコードを追加するコストを下げます。だからこそ、コードを追加しないという拒否の価値が高まります。

コンテキストは安全性の予算です

エージェントの安全性は、権限の問題として語られがちです。どのコマンドを実行できるのか。どのファイルを編集できるのか。どのシークレットを見られるのか。どのネットワーク呼び出しが許されるのか。どれも重要な問いです。しかし、作業中のエージェントが最初にぶつかる制約をすべて覆うものではありません。その制約とは、コンテキストです。

AnthropicのClaude Codeベストプラクティスガイドでは、コンテキストウィンドウには会話、メッセージ、読まれたファイル、コマンド出力が入ると説明されています。1回のデバッグ作業だけで、数万トークンを消費することもあります。² 同ガイドはまた、コンテキストウィンドウが埋まるにつれて、Claudeが以前の指示を忘れ始めたり、ミスを増やしたりする可能性があると警告しています。²

この警告により、サイズは安全性の性質になります。小さなコードベースなら、エージェントは不要なファイルで作業を圧迫されることなく、関連する範囲を読めます。小さなツールなら、機能、テスト、権限モデル、エッジケースを同時に視野に入れられます。小さな差分なら、レビュアーは生成された変更の山を追うのではなく、実際の変更点を見つけられます。

コンテキストの予算には、実務上3つの制限があります。

大きなシステムでも、安全にできます。ただし、より強い分解が必要です。コードベースを小さくできないなら、エージェントに見せる範囲を小さくします。1つのパッケージ、1つの境界づけられたサブシステム、1つの公開コマンド、1つのテスト対象、1つの所有ディレクトリです。

隠れた状態よりプレーンなファイル

McIlroyのオーラルヒストリーは、古い教訓に鋭い実用性を与えています。彼は「1つのことを行う」を、複数のことをする余地がなかったことから生まれた原則だと説明し、その制約がなくなったあともチームがそのパターンを使い続けたと語りました。⁴ さらに、テキストストリームが重要だった理由も説明しています。人間が読めるデータはデバッグを楽にし、変化するテキストフィールドは固定されたバイナリレイアウトを変えるより少ない手間で済みました。⁴

エージェントにも同じ種類の接点が必要です。ファイルは一覧化でき、検索でき、差分を取れ、範囲指定で読め、コミットでき、戻せ、lintでき、レビューできます。隠れたIDE状態、不透明なローカルデータベース、広範なホステッドツールも有用な場合はあります。しかし、それらはエージェントとレビュアーに、簡単には確認できない接点を信頼するよう求めます。

2026年1月のarXiv論文は、Unixのファイル抽象をエージェント型AIシステムに結びつけています。その論文は、ファイルのような抽象とコードベースの仕様が、多様なリソースを一貫した組み合わせ可能なインターフェースへまとめ、エージェントシステムの保守性、監査可能性、運用上の健全性を高める可能性があると論じています。⁶ Oracleのエージェントメモリ分析も関連する区別をしています。ファイルシステムのインターフェースがうまく機能するのは、モデルがリポジトリ、フォルダ、Markdown、ログ、CLI操作のような開発者になじみのある接点をすでに理解しているからです。一方で、永続的な保存はデータベースが担うべき場合もあります。⁷

この区別は重要です。「ファイルを使う」は、「すべてをばらばらのテキストに永久保存する」という意味ではありません。より安全なパターンは、エージェントのインターフェースと保存基盤を分けます。

エージェントには、役に立つ範囲で最小のインターフェースを見せるべきです。プロダクトは、その下により強い保存レイヤーを持てます。

ツールが少なければ権限も少なくなります

MCPの認可に関する記事は、認可の教訓を明確にしました。ベアラートークンを検証しても、そのユーザーがサーバーの背後にあるすべてのツールを呼び出してよいことの証明にはなりません。⁸ 小さなソフトウェアは、同じ考え方をデザインのさらに早い段階に適用します。小さなツールは、より狭い権限だけを求めます。

OpenAIのローカルシェルに関するドキュメントは、危険性を率直に述べています。任意のシェルコマンド実行は危険になり得るため、ビルダーはシステムシェルへコマンドを渡す前に、実行をサンドボックス化するか、厳格な許可リストと拒否リストを追加すべきです。³ AnthropicのClaude Codeガイドは、規模が大きい場合の実践例も示しています。ファイル群に処理を広げるときは、許可されたツールの制限を使い、無人実行が必要以上のことをできないようにします。²

小さなコマンドは制限しやすくなります。

広いツールは、広い権限をため込みがちです。汎用的な「公開」コマンドは、コンテンツ、翻訳、データベース行、キャッシュ削除、デプロイログ、アナリティクスに触れるかもしれません。リリースコマンドが必要な場合もあります。より安全なパターンは、明示的な基準を挟んだ小さなコマンドからリリースを組み立て、各ステップに証拠がそろってから、その順序を自動化することです。

目的は作業を遅くすることではありません。権限を見えるようにすることです。

テストはツールに合う大きさにします

Anthropicのベストプラクティス第1節は、Claudeに作業を検証する方法を与えるよう求めています。テスト、スクリーンショット、期待出力、コマンドチェックです。² 小さなソフトウェアは、この助言を具体化します。小さなツールなら、小さな検証契約を持てます。

エージェントが作るソフトウェアでは、その契約は1画面に収まるべきです。

Inputs:
- one source path
- one output path
- one optional flag

Allowed effects:
- read source path
- write output path
- no network unless --verify-sources is present

Evidence:
- unit tests for parsing
- fixture test for output
- dry-run output for the exact file
- git diff limited to owned paths

この契約が重要なのは、エージェントがあいまいな依頼を簡単に満たせてしまうからです。「パイプラインを改善して」は、アーキテクチャ変更の誘いになります。「この1つのコマンドにdry-runフラグを追加し、出力がファイルを書き込まないことを証明して」は、証拠の経路を作ります。

ツールが小さければ、テストも速くなります。速いテストはエージェントの振る舞いを変えます。エージェントはテストをより頻繁に実行し、関連コードがまだコンテキストにあるうちに失敗を見て、作業ログが流れていく前に根本原因を直せます。遅いテストは、モデルを推測や「実行したつもり」の説明へ押しやります。

小さいことは作り込み不足ではありません

小さなソフトウェアは、予測しやすい形で失敗することがあります。

フロッピーバッジが測るのはサイズです。エージェントの安全性には別の測定が必要です。変更を承認する前に、レビュアーは振る舞い、権限範囲、証拠の経路を理解できるでしょうか。

この問いは、ツールが1.44 MBを超えることを許します。一方で、重要な部分は拒否します。偶発的な範囲拡大です。安全で退屈な20 MBのネイティブアプリは、レビューされていないインストーラーをシェル経由で呼び出す200 KBのスクリプトより優れていることがあります。小さなソフトウェアが安全性に役立つのは、節度が実際の実行経路にまで届くときだけです。

エージェント作業のための小ささスコアカード

エージェントがツールを作成または変更する前に、5つの観点で作業を採点します。目的は大きなシステムを罰することではありません。エージェントが書き始める前に、分解が必要な接点を見つけることです。

赤いセルがあるからといって、作業を止めるべきだという意味ではありません。赤いセルは、エージェントにもっと小さな作業単位が必要だという意味です。正しい振る舞いを証明しやすいタスクの形にすると、安全性は高まります。

実践パターン

私が信頼している、エージェントが作った安全なシステムには共通した形があります。

1. 狭い1つのコマンドが、1つの仕事をします。
2. 入力、出力、ログ、計画、レビューパケットはプレーンなファイルで運ばれます。
3. 権限は、コマンドの実際の効果に対応します。
4. テストは、エージェントが作業中に使えるほど速く走ります。
5. 差分は、人間がレビューできる程度に小さく保たれます。
6. リリース経路は、広い権限を1つのボタンの中に隠すのではなく、小さなコマンドを組み合わせます。

No-Build宣言：バンドラーなしで出荷するでは、同じ好みをWebスタック側から説明しました。ビルドレイヤーを減らし、生成成果物を減らし、ソースと実行時の距離を縮めるという考え方です。⁹ エージェント安全性の版では、読者を変えて同じことを言っています。余分なレイヤーはすべて、機械がもっともらしい作業を生み出し、人間がすばやく検証できない場所を増やします。

小さなソフトウェアは、節度をインフラに変えます。狭いモジュールはコンテキストに収まりやすくします。プレーンなファイルは監査しやすさを高めます。速いテストはフィードバックを改善します。小さな権限セットは影響範囲の制御を改善します。小さな差分は人間の判断を助けます。

FAQ：小さなソフトウェアとエージェントの安全性

小さなソフトウェアにすれば、AIコーディングエージェントは安全になりますか？

いいえ。小さなソフトウェアは、エージェントが誤解したり壊したりできる範囲を減らします。それでもチームには、サンドボックス、許可リストと拒否リスト、テスト、コードレビュー、認証情報の境界、リリース基準が必要です。小さなソフトウェアは、それらの制御を適用しやすくし、偶然すり抜けにくくします。

エージェント向けツールはどれくらい小さくするべきですか？

有用な基準はバイト数ではなく、レビューしやすさです。よいエージェント向けツールには、1つの仕事、小さな入出力契約、明確な権限プロファイル、速いテスト、そしてレビュアーが一度で理解できる差分があります。

エージェントメモリにはファイルとデータベースのどちらを使うべきですか？

エージェントが成果物を確認し、検索し、差分を取り、書き込む必要がある場合は、インターフェースとしてファイルを使います。プロダクトが並行性、インデックス、アクセス制御、耐久性、ユーザーをまたぐ状態を必要とする場合は、データベースを使います。より安全なアーキテクチャは、エージェントに見せるインターフェースと保存基盤を分けます。⁷

MCPはどこに当てはまりますか？

MCPは、エージェントが外部ツールやデータへ型付きの橋を必要とするときに当てはまります。MCPがあっても、小さなコマンド、範囲を絞った権限、アクション単位の認可は不要になりません。サーバーは依然として、特定の主体が特定のアクションを実行してよいかを判断しなければなりません。⁸

おわりに

AIはコードを安くします。コードが安くなるほど、拒否の価値は上がります。

小さなソフトウェアは、機械が従える形を拒否に与えます。1つのコマンド、1つの出力、1つの権限境界、1つのテスト経路、1つの差分。その形は品質を保証しません。それでも、弱い仕事を見えやすくします。

もはや制約はフロッピーディスクではありません。検査しやすさです。

参考文献