エージェントによるソフトウェアの個人化革命：設定ファイル不要の時代

現状と課題：自作ソフトウェアの希少性

かつてはエンジニアであっても、自分自身のために開発したプログラムを所有している者は稀でした。

• 使用スタイル: 多くのエンジニアは他人が書かれたコードを使いながら、同時に自らのためにも別のツールを作っていました。
• カスタマイズの限界: 設定ファイルやプラグインで少し変更する程度でしたが、完全な独自ソフトウェアを持つことは珍しく、市販製品の静的サイトジェネレーターなどに頼る方が一般的でした。
• 過去の経験:
  • 自作ソフトウェアへの投資はリターンが見えず疑問視されました。
  • 開発時間は限られており、より重要な業務があるため「断念」する人が多くいました。
  • プロジェクトのメンテナンス（1 年後のリターン等）は苦痛であり、結果として標準環境でのみコードを記述していました（著者の初期グーグル時代には PC を所有していなかった例も）。

ソフトウェア個人化の実現方法

現在は、エージェントを活用することで個人化が驚くほど容易になりました。主なアプローチは以下の 2 つです。

• ローカル構築とバージョン管理:
  • エージェントに

    <software>

    のソースコードを取得し、ローカル環境で構築させる。
  • 将来的な変更については、メモリ領域に記録し、バージョン管理システムにも動機を記録する。
• 自動化された同期（クロンジョブ）:
  • 毎夜実行されるタスクで、アップストリームの最新の変更を取得する。
  • ローカルでの変更を再統合（rebase）し、動作確認と更新を自動で行う。

核心的な価値: エージェントが単なるハッキングではなく、自動的な変更同期プロセスも管理できることです。これにより、個人化の「開始」も「維持」も格段に容易になります。

アジェンツへの組み込み

これらのプロンプトはエージェント自体に組み込むことが可能です。

• スキルのロード: オープンソースのエージェントであれば、プログラミング不要で、特定箇所に配置された**テキスト指示（スキル）**として動作します。
• Shelley の事例: 著者のシェルレイ（Shelley）では、事前設定やタイマー設定が不要です。
  • 例:

    make Shelley's UI high-contrast

    というプロンプトを入れるだけで、UI を高コントラストモードに個人化できます。

具体的なカスタマイズ事例：Shelley と Meat

著者が開発中の個人的プロジェクト「Meat（meat.dev）」と、それを実行するエージェント「Shelley」の連携を例に解説します。

• 基本原則: エージェントがコードを書く間も、プッシュ前に手動レビューを行います。
• AI の進化による変化:
  • 人間はエッジケース（エラーレポートの有無、Nil チェックなど）を探すのに苦戦しますが、LLM はそれらを非常に正確に処理します。
  • AI のエラーは主にアーキテクチャや予期しないユースケースに限られます。
  • その結果、レビュー対象となるコードの大部分は無意味となり、AI が不要な部分をフィルタリングするツールが開発されました。
• Meat の活用: 差分（diff）からインポートブロックやエラーハンドリングを隠蔽し、「中身」だけに集中できるようにしました。

Meat を Shelley に統合するためのワンショットプロンプト

複雑な設定ではなく、以下の単一のプロンプトで機能を追加できました。

please build meat.dev into Shelley. 最新版を PATH にインストールしてください。Shelley が git コミットを作成した際、バックグラウンドで meat の処理を開始してください。Shelley の Diffs ビューに meat の切り替えボタンを追加し、コミットがまだ処理中である場合はユーザーに対して処理中であることを表示してください。

• 効果: セッションに戻る前に自動的にコミットを事前処理し、待ち時間を削減しました。
• 注意点: 当初の試行では切り替えボタンに🥩（肉の絵文字）を使用しましたが、これは不具合の一つでした。
• 代替案の検討: VS Code 拡張機能や vimdiff の統合は複雑で悲惨ですが、外部プロセス

  meatd

  を実装しファイルシステムを監視するアプローチの方が適切であると考えられます。拡張や設定のポイントではなく、ソースコードそのものが重要です。

個人化可能なソフトウェアの時代へ

従来の開発コストと比較すると、以下のようにパラダイムが変化しました。

• 固定費と変動費の消失:
  • 複雑なソフトウェアには大規模な設定ファイルやプラグインシステムが必要でした（例：Vim のコアコードを理解するのに数週間かかるなど）。
  • これらのコストを共有することで正当化されていましたが、現在はコストが劇的に低下しました。
• エージェントの役割:
  • エージェントが重い処理を引き受け、単一ユーザー向けソフトウェアでは1 ショットで機能を追加可能です。
  • 慎重なコードレビューも、「動いているように見えるか？」という簡易チェックに置き換わります。
• プラグイン不要:
  • テキストエディタのフォントサイズ変更など、ハードコーディングされた値であればエージェントが即座に編集します（別のフォントをダウンロードするか、Monobit で作成するなど）。
  • あなたの手元には信じられないほどの能力が眠っています。

全体的なソフトウェア製品の再考案

パーソナルソフトウェアの考え方は、中小チームや企業全体にも適用可能です。

• 現状の問題: エンジニアリングチームが非常に設定可能なタスクマネージャー（CMS や CRM）を購入し、学習と設定に時間を費やすのは非合理的です。
• 解決策: 共通の構成要素から必要な機能を組み立てるべきです。
• 結論: ソフトウェアを個人化する際の初期固定コストと継続コストがほぼ消滅しました。

重要: 企業がエンドユーザー向け製品として意味を持ち続けるためには、**個人化可能である（ソースコードを持つ）**必要があります。ブログも Shelley で書かれた特注型ソフトウェアとして、既存のライブラリを組み立てる方がカスタマイズしやすいという実例があります。

Codex と Claude Code の分岐点：オープンソース vs クローズドソース

このスキルベースの技術は、以下のように適用可能です。

• Codex（オープンソース）:
  • Shelley への個人化技術をそのまま適用可能。
  • トークン消費量は増えますが、実装が可能です。
• Claude Code（クローズドソース）:
  • 壁に直面: 個人化ができません。
  • カスタマイズフックが存在しないため、理想とするエージェントの動作パターンがフィットしにくい可能性があります。
  • 戦略: フィットしない場合は、個人化可能な別のエージェントへ切り替える必要があります。

総評: ソースコードこそが真の拡張システムであり、クローズドソース製品への依存は自由な個人化を妨げます。