AIツールの「入社試験」——新しいツールを導入する前にやっていること
AIツールが毎週のように出てくる今、どれを使うべきか判断するのが一番難しい。エンジニアとしてのツール評価フレームワーク「入社試験」の考え方と評価軸を紹介。
エンジニアのゆとです。
AIツールが毎週のように出てくる。毎日Xを開くと「革命的な新ツール！」みたいな投稿が流れてきて、全部試してたら1日が48時間あっても足りない。
じゃあどれを試して、どれをスルーすべきか。この判断が、今のAI時代に一番求められるスキルかもしれない。
自分はこれを**「入社試験」**と呼んでいる。新しいツールが出てきた時に、実際に自分のワークフローに採用するかどうかを判断するためのプロセスだ。
なぜ「入社試験」なのか
会社が人を採用する時、履歴書だけで決めないのと同じ。
READMEの説明やデモ動画がどれだけ華やかでも、実際に自分のプロジェクトで使えるかは別問題。「面接して、試用期間を設けて、合わなければ不採用」——ツール選定もこのプロセスが必要だと思っている。
特にAIツールは「デモは凄いけど実務では微妙」というパターンが多い。Gartnerが2027年末までにAIエージェントプロジェクトの40%超が中止されると予測しているのも、この「デモと実務のギャップ」が原因の1つだと思う。
入社試験の評価軸
自分がツールを評価する時に見ているポイントは5つ。
1. 何を解決しようとしているか（課題の明確さ）
そのツールが解こうとしている課題は、自分も抱えているか？
「すごいツールだけど、自分にはその課題がない」というケースが一番多い。逆に、自分がまさに困っていたことをピンポイントで解決してくれるなら、多少の粗さは許容できる。
2. コードを読めるか（透明性）
OSSなら最優先でコードを読む。
プロンプトの中身、API呼び出しの実装、エラーハンドリングの有無。これを見ると、作者がどれだけ実務を理解しているかがわかる。逆に、クローズドソースでブラックボックスなツールは慎重になる。
「何をやっているかわからないツールに、自分のデータを渡したくない」というのは、エンジニアとして当然の感覚だと思う。
3. 自分で作れるか（代替コスト）
「これ、自分で2時間で作れるな」と思ったら、そのツールの価値はUIの利便性だけ。
逆に「この設計思想は自分では思いつかなかった」「このプロンプト設計は参考になる」と感じたら、たとえ不採用でも学びがある。入社試験は「採用/不採用」の二択じゃなくて、学びの機会でもある。
4. コストは現実的か（料金と依存度）
無料枠があるか、従量課金か、月額固定か。
そして見落としがちなのが依存度。そのツールが止まったら自分のワークフローも止まるのか、代替手段はあるのか。ツールへの依存度は「採用」のリスクそのもの。
5. 既存のワークフローに馴染むか（統合コスト）
どれだけ優れたツールでも、既存の環境に組み込むのに3日かかるなら、そのコストに見合うだけの価値が必要。
CLIで完結するのか、GUI必須か。APIがあるのか、MCP対応しているのか。自分のClaude Code環境に自然に統合できるかどうかは、大きな判断基準になる。
実際の入社試験プロセス
- 書類選考: READMEとデモを見る。課題が自分に関係なければここで終了
- 一次面接: コードを読む。アーキテクチャと設計思想を理解する
- 技術試験: 実際に動かしてみる。自分のユースケースで試す
- 最終判定: 採用（導入）/ 条件付き採用（参考にする）/ 不採用（スルー）/ 保留（技術は面白いが今じゃない）
全部やると1ツールあたり1-2時間。でもこの投資をしないと、「なんとなく入れてみたけど結局使ってない」というツールゾンビが増えるだけ。
判定結果の4段階
採用: ワークフローに組み込む。設定ファイルに追加し、日常的に使う。
条件付き採用: コードや設計思想は参考にするが、そのまま使うのではなく自分の環境に合わせてカスタマイズする。OSSツールに多いパターン。
不採用: 自分のユースケースには合わない。ただし、別の人には有用かもしれないので否定はしない。
保留: 技術的には面白いが、今の自分には必要ない。半年後に状況が変わったら再評価。
入社試験シリーズ
この考え方に基づいて、実際に気になったAIツールを入社試験していく。
今後も面白いツールが出てきたら入社試験を実施して、このブログで結果を共有していく予定。「採用」「不採用」の判断理由を含めて書くので、ツール選定の参考にしてもらえたら。
