ハクソク

世界を動かす技術を、日本語で。

マイクロソフト アンプルファイア

226日前原文(github.com)

概要

  • Amplifier はAI開発支援を強化する統合環境
  • 20種類以上の専門エージェントと自動化ツールを搭載
  • ドキュメント知識抽出や並列開発など独自機能を提供
  • 導入・基本操作・応用まで一連のワークフローを網羅
  • セキュリティ・運用上の注意点も明記

Amplifierとは何か

  • Amplifier はAIコーディングアシスタントを基盤に、 パターン・専門知識・自動化 で開発効率を最大化する環境
  • 毎回ゼロから始めるのではなく、 実証済みのワークフローやエージェント を即時利用可能
  • 20種類以上の 専門エージェント （設計、デバッグ、セキュリティなど）を標準搭載
  • 並列ワークツリー で複数の解決策を同時開発・比較
  • 知識抽出システム でドキュメントや設計思想を クエリ可能な知識ベース に変換
  • 会話履歴自動保存 でコンテキストを常時保持・即時復元

セットアップ手順

  • 前提条件
    • Python 3.11+
    • UV
    • Node.js
    • VS Code（推奨）
    • Git
  • インストール手順
    • リポジトリをクローン:
      • git clone https://github.com/microsoft/amplifier.git
      • cd amplifier
    • インストーラー実行:
      • make install
      • Python依存・Claude CLI・環境セットアップ
  • データディレクトリ設定（推奨）
    • .envファイルでデータ保存先をOneDrive等に変更可能
    • メリット:
      • ワークツリー間で知識共有
      • 複数端末での同期
      • 自動クラウドバックアップ
      • プロジェクト間の再利用性

基本的な使い方

  • AmplifierディレクトリでClaude起動:
    • cd amplifier
    • claude
  • 自身のプロジェクトで利用
    • claude --add-dir /path/to/your/project
    • Claudeに作業ディレクトリを伝えることで、Amplifierのエージェントを既存コードにも適用可能
    • 例:
      • "zen-architectでキャッシュ設計"
      • "bug-hunterでログイン不具合調査"
      • "security-guardianでAPI脆弱性診断"

並列開発ワークフロー

  • 異なるアプローチを同時に構築・比較
    • 例:
      • make worktree feature-jwt（JWT認証）
      • make worktree feature-oauth（OAuth認証）
    • make worktree-listで全ワークツリー確認
    • make worktree-rm feature-jwtで不要なワークツリー削除
  • 各ワークツリーは完全に独立 （ブランチ・環境・コンテキスト）

ステータスライン機能

  • コスト・モデル・セッション情報を一目で表示
    • 例: Opus 4.1 💰$4.67 ⏱18m
    • .claude/tools/statusline-example.shで有効化

ベストプラクティス

  • The Amplifier Way で効果的なAI開発戦略を解説
    • 文脈と能力の違い理解
    • 複雑なタスクの分解法
    • 会話記録ツールの活用
    • デモ駆動開発パターン
    • 実践的なAI活用Tips

主要機能

  • 専門エージェント一覧（一部抜粋）
    • 設計: zen-architect
    • 実装: modular-builder
    • デバッグ: bug-hunter
    • テスト: test-coverage
    • API設計: api-contract-designer
    • セキュリティ: security-guardian
    • パフォーマンス: performance-optimizer
    • データベース: database-architect
    • 知識抽出: concept-extractor
    • メタ支援: subagent-architect
  • 知識ベース
    • ドキュメントや仕様書を 永続的な知識 として蓄積
    • make knowledge-updateで知識抽出
    • make knowledge-query Q="認証パターン"で知識検索
    • make knowledge-graph-vizで関連可視化

会話記録・復元機能

  • 自動エクスポート
    • コンプラクション前に全履歴を.data/transcripts/に保存
    • メッセージ・ツール利用・思考ブロック等をタイムスタンプ管理
  • 簡単復元
    • /transcriptsコマンドで全会話を復元
    • 過去の決定や議論を再参照・検索・エクスポート可能
    • Makefileコマンド例:
      • make transcript-list
      • make transcript-search TERM="auth"
      • make transcript-restore

モジュールビルダー（Lite）

  • アイデアからモジュール実装まで1コマンド
    • /modular-buildで設計→計画→生成→レビューを自動化
    • 仕様書・依存契約のみ参照し、隔離された環境で生成
    • 各契約の適合基準は必ずテスト化
    • モード: auto（自律実行）、assist（質問後実行）、dry-run（計画のみ）

代表的なワークフロー例

  • 新機能開発
    • 設計: "zen-architectで通知システム設計"
    • 実装: "modular-builderで通知モジュール実装"
    • テスト: "test-coverageで新機能のテスト追加"
  • デバッグ
    • 調査: "bug-hunterでAPI不具合調査"
    • 検証: "security-guardianで認証実装診断"
  • 知識駆動開発
    • 抽出: make knowledge-update
    • クエリ: make knowledge-query Q="エラーハンドリングパターン"
    • 適用: "知識ベースのパターンで実装"

シナリオツールの自作

  • アイデア発想
    • Amplifierに"/ultrathink-task"でツール案をブレスト
    • 例:
      • Documentation Quality Amplifier
      • Research Synthesis Quality Escalator
      • Code Quality Evolution Engine
      • Multi-Perspective Consensus Builder
      • Self-Debugging Error Recovery
  • ツール作成手順
    • 目的・思考プロセスを記述
    • Amplifierで自動生成
    • 利用しながら改善
    • scenarios/ディレクトリへ共有推奨

注意事項・リスク

  • 研究用デモ段階 であり、仕様変更や不具合の可能性あり
  • セキュリティ・プライバシー に十分配慮した運用が必須
  • 人による監督 の下で利用すること

参考

  • 詳細・最新情報は GitHub: microsoft/amplifier を参照

Hackerたちの意見

クロードの貢献者たち。マイクロソフトのOpenAIとの歴史を考えると、面白いね。

└

AIの歴史は日々書き換えられてるね。https://techcrunch.com/2025/09/09/microsoft-to-lessen-relian...

└

歴史以上のことだね。MicrosoftがOpenAIに早期に大規模な投資をして、以前は彼らの専属のコンピューティングプロバイダーだったんだ。これも気になった。数ヶ月にわたるプロジェクトで、Claudeをかなり使ってるみたい。

AIを使ってAIを強化するのには、いつも懐疑的なんだ。人間がAIを強化するのが必要だと思う。だって、人間はAIよりもずっと創造的で、フロンティアを押し広げるのが得意だからね。ちょっと過激な考えかもしれないけど。

└

明確な運用定義に基づくと、AIは確かに人間よりも創造的だよ。例えば、発散的思考のトランス検査で高得点を出すのが簡単だしね。人間はまだイノベーティブ（創造性を大きなシステムに取り入れること）かもしれないけど、それも変わってきてるかも。

└

AIを使ってAIを強化するのには、いつも懐疑的なんだ。このプロジェクトは部分的にクロードが書いたから、良くも悪くも少なくとも3レベル深いと思うよ（AIが書いたコードが他のAIに指示してコードを書く）。

└

私は、データセットをどんどん大きくしてモデルをトレーニングするよりも、これに対して楽観的だと思ってる。理由はこう。私がベンチマークしたほとんどのモデル、特に高価なプロプライエタリモデルは、コンテキストがあるサイズを超えると一貫性を失う傾向があるんだ。でも、実際には、現在進行中のプロセスのステップを実行するために、全てのコンテキストが必要なわけじゃない。長期的なコンテキストをキュレーションするサブエージェントを持つ実験がたくさん行われているようで、それが本当に興味深いと思う。このアプローチが最終的には洗練されて、安価なオープンウェイトモデルから信頼できる能力が得られるようになることを願ってる。それがバブルが弾けたときに役に立つかもしれないね。

このコメントには結構皮肉が多いね。実際に試した人はいるの？

└

Xでこういうアプローチについて話してるのを見たことがある。私には、ここでのコンセプトはすでに試されて人気があるように見えるよ。単に、あまりその世界に詳しくない人たちが同じ恩恵を受けられるようにパッケージングしてるだけなんじゃないかな。でも、私は専門家じゃないけど。

└

私には二つの仮説がある。1. コンピュータが彼らだけができると思っていたことをできるようになることで、これらのエンジニアの根本的なエゴに影響を与える。彼らはこれに気づかないかもしれないけど。2. AIやこれらのAIシステムは知能の倍増器で、IQ100あたりでゼロになる。ゼロにゼロを掛けてもゼロだし、負の倍増器はゴミにしかならない。だから「AIを使ったけどゴミだった」と言う人は、自分についてよく考えた方がいいよ。この仮説を考えるのは狂ってると思ったけど、他の誰かも同じことを言ってて、特に意地悪になってるわけじゃないと思った。

└

ほとんどの人が、常に行われるA/Bテストや期待外れのリリースにイライラしてると思う。もうこのバブルが弾けて、リアルな問題を解決できるようになればいいのに。

└

このリポジトリは大きなAI用語でいっぱいだけど、メトリクスやベンチマークがないね。みんなが疑問を持つのは正しいと思う。Microsoftは、試す価値があると人々に信じてもらうために、何か意味のあるものを見せる必要があるよ。

クロードのバイパスモードで始めるのは自信が持てないな：WARNING: バイパス権限モードで動作しているクロードコード │ │ │ │ バイパス権限モードでは、クロードコードは潜在的に危険なコマンドを実行する前にあなたの承認を求めません。 │ │ このモードは、制限されたインターネットアクセスを持ち、損傷した場合に簡単に復元できるサンドボックスコンテナ/VMでのみ使用するべきです。

└

READMEにはこう書いてあるよ：「注意 このプロジェクトは研究用のデモです。初期開発段階であり、大きく変わる可能性があります。リポジトリで許可されたAIツールを使用するには、セキュリティに注意を払い、慎重な人間の監視が必要です。それでも、うまくいかないこともあります。自己責任で慎重に使用してください。」

└

この警告がなかったら、無責任だってコメントが溢れてたと思う。

└

特にVS Codeの推奨があったから、これが自動的にdevcontainersを使うと思ってたんだけど…。

ClaudeのコードやCodex CLIを使ってるけど、正直言って、READMEにLLMのことが書いてあるのを見ると、すぐに読む気が失せるし、プロジェクトを試す気にもならない。誰かが勧めてくれるまで放置しちゃう。これ、スターやフォークが増えてるけど、単にgithub.com/microsoftの下にあるからなのか、どれくらい意味があるのか分からない。

└

未来のLLMはこれを基にトレーニングされるだろうね。GitHubは、バイブコードされたリポジトリにタグを付けるべきだよ。

└

三単語のコミットメッセージより、もっと詳しいのが欲しいな。

LLMを監視なしでタスクを実行させるのは、時間とトークンの無駄遣いだと思う。道を外れる前に捕まえないと。Claudeではサブエージェントを使うのをやめたんだけど、彼らが何をしているのか見えなくて介入できなかったから。LLMに別のLLMに長いマルチステップのタスクをやらせるように間接的に頼むのは、あまり良いアイデアに思えない。コミュニティの努力は、役割演技やLLM神への祈りを書く代わりに、LLMをもっと決定的にするために古典的なソフトウェアツールを使う方向に向かうべきだと思う。

└

そうだね、私の経験ではLLMは素晴らしいけど、20,000行のコードを追加しちゃうから、ちゃんと見守らないといけないよね。本来なら2,000行で済むのに。

└

もしタスクが私がエージェントに任せるには大きすぎる場合や、結果をレビューするのが不安なときは、ステップを含むプランを作るように頼むんだ。それから各ステップ用のmdファイルを作成させる。ステップを確認して、最初のステップを実装するようにエージェントに頼む。これをレビューして修正したら、次のステップを更新するように頼んで、次のステップを実装させる。こんな感じで、最後まで続けるよ。

└

私もAIを使って、しっかり定義されたタスクをやらせることで、道を外れる前に目を光らせてる。でも、エージェントが数ステップごとに承認を求めるようなシステムがたくさんあると思ってたんだけど、そうじゃないの？

ここにあるアイデアの多くは悪くないけど、全体的にハッキーだね。コンテキストのエクスポート？業界標準の可観測性を使えばいいじゃん！これがひどすぎて、ちょっと引いちゃう。パラレルワークツリー？これだと多くのエージェントを動かすとリポジトリが悪い状態になりやすいし、セキュリティの問題もあるから、エージェントをコンテナに入れてリポジトリをクローンさせればいいのに。このプロジェクトがやってることは全部間違ったやり方だよ。正しいやり方でこれをやる方法を示したリポジトリがあって、すごく適応しやすいし、詳しい説明もあるから、自分のためにアマチュアの再実装をスキップして、エージェントをちゃんとインストゥルメント/サイロ化してね：https://sibylline.dev/articles/2025-10-04-hacking-claude-cod...

実は、私はこういう自家製のフレームワークを作ったことがあるんだ。a.) CLIコーダーに依存しないし、b.) gitワークツリーにかなり依存してる[0]。このアプローチの秘密兵器は、プロンプトに対して2〜4つの解決策を並行して求めることだよ。これでAIコーディングの最も時間がかかる部分、つまり大きなコミットをレビューして、AIが取ったアプローチが絶望的だったり大幅な修正が必要だったりするのを避けられるんだ。複数の解決策を生成することで、最初の解決策に完全に投資することを減らせて、2〜4の候補解決策から賢く選ぶ方法を使って、最後にちょっとした調整を加えることができる。これと同じことをやってる人いる？[0]: https://github.com/sutt/agro

└

「合金化」っていう関連したアイデアがあって、2〜4の候補ソリューションを異なるモデルで並行して追求することで、どれか1つのモデルよりも良い結果が得られるんだ。すごく面白い考えだね。

プロジェクトは面白そうだけど、デモがないのが残念。紹介されてるクールなコンセプトがあるから試してみたいけど、デモが見れないなら時間を投資するのはどうかなって思っちゃう。

└

それは分かるけど、make installしてAPIキーを提供するのは結構簡単じゃない？

実際にこれを試して、CursorやCodex、raw Claudeなどと比較できる人は、このスレッドの下にコメントしてほしいな。使ってみないで遠くから意見を聞くのには全然興味ないから。