「使えるか？」で読む今週の技術トレンド3選 ―選び方×自動化×チーム化―（2026/03/22〜2026/03/28）

今週の結論3点

144種類のエージェント定義をコピペで使えるOSS（agency-agents）が登場。ツールに専門知識を後から注入できるようになってきた

コーディング補助のCLIエージェントは3社とも「使えるレベル」に来た。差は性能よりも、料金体系とエコシステムの方向性

Claude Codeは「毎回プロンプトで頑張る」から「仕組みで品質を担保する」方向に進化している

導入

今週は『道具をどう選ぶか』と、『選んだ道具をどう仕組みに変えるか』が軸でした。

CLIエージェントの3社比較記事が注目を集め、「どれが最強か」から「どのエコシステムに乗るか」という問いにシフトしています。

あわせて、Claude Codeを自動化の基盤として使う手法が具体的な形になってきました。プロンプトを磨く時代から、仕組みとして回す時代に変わりつつあります。

Claude Code・Gemini CLI・Codex CLIの3社を「業務外の個人利用・CLI操作を中心に」比較した記事です（2026年3月時点のスナップショット）。

主な違いをまとめると：

• Claude Code：業務の定番。外部ツールへの組み込みを前提にした設計で、『エージェントの基盤を提供する』方向性が強い
• Gemini CLI：オープンソース。1日1,000リクエストまで無料で使える。やりとりできる量も大きく、有料プランなしで実用的に試せるのが強み
• Codex CLI：OpenAI製。実行時の安全性を段階的に設定できる仕組みが特徴。クラウド側での非同期実行にも対応している

コーディング性能は3社とも「どれを選んでも困らないレベル」という評価でした。

技術的なポイント

・今どのツールを選ぶかより、選んだ後の使い込みが差になってくる（記事の結論より）
・Gemini CLIは無料枠が広いため、まず試してみる目的に向いている
・Claude CodeはAPIや外部ツールとの連携設計が前提。将来的に仕組みとして組みたいなら選ぶ理由になる

実務ポイント

・新しいプロジェクトで迷ったら「料金」と「将来どのエコシステムで動かすか」の2軸で絞り込む
・個人利用と業務利用で、選ぶ基準を変えていい

今後3社の差はさらに縮まっていくと思われます（推測）。「最強のツールを追い続ける」より「1つを選んで深く使いこなす」方向に時間を使った方が、実務での費用対効果は高そうです。

② Claude Codeを『仕組み』として使う：4層ハーネスとengramの話

今週のエンジニア向けダイジェスト記事で紹介されていた内容です。

Claude Codeを単体で使うのではなく、以下の4つを組み合わせて「タスクの指示からPRのマージまでを自動化する」構成の解説でした。

• hooks：タイミングに合わせた処理を差し込む仕組み
• Lefthook：コードの品質チェックを自動で走らせる仕組み
• スキル：よく使う指示を再利用できる形でまとめたもの
• GitHub Actions：一連の処理を自動で実行する仕組み

あわせて「engram」というMCPサーバーの紹介もありました。Claude Codeはセッションをまたぐと文脈が消えてしまいますが、これを解消するためにSQLiteと検索の仕組みを組み合わせて、過去のやりとりを記憶として持たせる設計です。

技術的なポイント

・4層構造のポイントは「いつ・何を・どの順で動かすか」を事前に設計するところ
・engramはSQLiteと検索の仕組みを組み合わせて、セッションをまたいだ文脈の消失を防ぐ設計
・どちらも「毎回プロンプトで指示する」から「仕組みで担保する」方向への転換を表している

実務ポイント

・まずは『スキル（再利用できる指示）』だけでも作ると、繰り返し作業の手間が下がる
・4層すべてを一度に組もうとすると複雑になりやすい。1層ずつ試す順番が現実的（推測）
・繰り返し発生している作業から先に仕組みにしていくのが、再現性の高い進め方

「毎回プロンプトを工夫する」から「仕組みとして動かす」への移行は、これまでのCI/CD（継続的にテストとリリースを自動化する考え方）と近い設計思想です。まず一番繰り返している作業を1つ特定するところから始めやすいでしょう。

③ agency-agents：144種類のエージェント定義をコピペで使う

144種類のAIエージェント定義をMarkdownファイルで提供するOSS「agency-agents」の紹介記事です。Claude Code・Copilot・Cursor・Gemini CLIなど10種以上のツールに対応しています（2026年3月14日時点でスター数4万超）。

「開発者として機能して」という汎用的な指示との違いは、専門領域ごとの知識体系が構造化されている点です。たとえばFrontend Developerエージェントなら、画面の表示速度や安定性を測る指標（Core Web Vitals）の改善提案まで含まれています。

ファイルはMarkdownなので、自分のプロジェクトに合わせてエディタで自由に編集できます。

技術的なポイント

・汎用プロンプトとの差は「専門知識が最初から構造化されている」ところ
・Security Engineerエージェントなら、依存パッケージの問題チェックや入力バリデーションの観点が含まれている
・Markdownファイルなので、プロジェクト固有のルールを後から追記できる

実務ポイント

・まず試すなら「作る人」「セキュリティを確認する人」「品質をチェックする人」の3種から始めやすい
・エージェント同士の自動連携は現時点でなく、手動で切り替えながら使う運用（記事より）
・今自分が困っている専門領域に1種類だけ入れてみるところから始めると続けやすい

144種類という数は最初は多く見えますが、実際に使う種類は絞られていくと思います（推測）。設計思想の軸は「作る人とチェックする人を分ける」で、通常のコードレビュー文化と近い考え方です。

まとめ

今週のキーワードは、『選んで、仕組みにして、専門化する』でした。

CLIエージェントの選び方の基準が「どれが高性能か」から「どのエコシステムに乗るか」にシフトしています。Claude Codeを中心に、プロンプトではなく仕組みで動かす設計が具体的な形になってきました。

agency-agentsのように「専門知識を後から注入する」アプローチも出てきており、ツールをどう組み合わせるかより『何を担わせるかを先に設計する』時代に入った気がしています。