Career-Opsの内部構造：14モードSkillsアーキテクチャから学ぶClaude Code設計の実践【2026】

import PostCardLink from ’../../components/PostCardLink.astro’;

Career-Ops を初めて知った方は Career-Ops とは何か？ を先に読むのを推奨。30秒で全体像と設計思想を把握できる。本記事はアーキテクチャ深掘り。

Santiago Fernández de Valderrama が2026年初頭に career-ops をオープンソース公開したとき、1週間で GitHub スターが 0 から 44,554 に達した（2026年5月時点）。表層的な売り文句はシンプルだ。AIによる求職システムで、求人票を評価し、ATS最適化された履歴書を生成し、応募状況を追跡する。

ただ、この説明では本質を取りこぼす。

career-ops はオープンソースで参照可能な Claude Code Skills アーキテクチャ の中でも、特に丁寧に設計された実装の1つだ。Claude Code の上にマルチモードのエージェント系を構築する場合、このリポジトリは1行ずつ読む価値のある参照実装になる。

この記事では、14モード設計が機能する理由、AGENTS.md / CLAUDE.md の分割構造、そして自分の Skills システムに転用できるパターンを掘り下げる。求職に興味がない読者にも有益な内容を意識した。

なぜ career-ops は求職を超える価値を持つのか

GitHub にある Claude Code リポジトリの大半は、シングルパーパスのスクリプトか、エージェント CLI の薄いラッパーだ。career-ops はその一段上のカテゴリにいる。並列・非同期・継続的な利用に耐える本番運用級のマルチモードシステム だ。

数字が運用実態を物語る。

• 631 件の評価実行
• 354 通の ATS最適化済み PDF生成
• 680 URL 重複排除（再評価ゼロ）
• 68 件の応募提出（オファーごとにパーソナライズ）
• 122 URL 並列バッチ処理

Santiago はこのシステムで Head of Applied AI 職に就いた。システムが機能した事実より興味深いのは、同じアーキテクチャが求職以外のドメインに大きく転用できるという点だ。

転用先の例:

• マルチモードの顧客リサーチ系
• 文書評価パイプライン（法務、契約レビュー、デューデリジェンス）
• 非同期のコンテンツ制作（リサーチ → アウトライン → 草稿 → レビュー）
• 投資仮説の評価
• リード適格化とアウトバウンド・シーケンシング

Claude Code の Skill を1個ずつ書いてきて「これをどう本格的なシステムに育てるか」と悩んでいるなら、career-ops が答えを示している。

14モード Skills アーキテクチャ

career-ops の設計思想は、Santiago 自身の言葉に集約されている。「modes over one long prompt」（長い1つのプロンプトより複数のモードに分けろ）。

巨大な CLAUDE.md や、何でも詰め込んだ AGENTS.md の代わりに、振る舞いを 14 個の狭い Skill に分解した。それぞれが独立したコンテキスト、ルール、トリガー条件を持つ。

モード一覧

各モードは modes/ 配下の独立したファイルだ。ユーザーがモードを起動する（あるいはエージェントが文脈から推論する）と、そのファイルの指示だけがプロンプトに読み込まれる。

「長いプロンプト」より「モード分割」が優れる理由

具体的な利点が3つある。

1. 精密なコンテキストロード。 apply モード実行時に評価ルールを読み込まない。oferta 実行時にフォーム入力ロジックを読み込まない。モデルに渡るのは関連情報のみ。

これが効く理由は、Claude Code のコンテキストウィンドウがいくら広くても無料ではないからだ。毎ターン 8,000 トークンの無関係な指示を読み込むと、モデルは信号とノイズの選別に余計な計算を使う。

2. テストの独立性。 pdf モードのレンダリングルールを変えても oferta の評価ロジックを壊さない。各モードが独立して進化できる。

3. 機能の独立追加。 Santiago は初版リリースから3週間後に training モードを追加した。既存モードに依存しない構造だから、回帰テストの心配なくプラグインできる。

対比として、12,000行の単一 CLAUDE.md ですべてを処理する設計を考えてみる。新機能の追加が、既存機能への回帰リスクを連れてくる。Skills 分割なら、スケールを持続可能にできる。

10次元評価フレームワーク

oferta モードが単一の求人票を評価するとき、漠然と「合いそう」「合わなそう」とは返さない。10次元にわたる構造化されたスコアと、明示的な重み付けで結果を返す。

ゲート通過の次元（バイナリ・キルスイッチ）:

• Role Match（職務適合）
• Skills Alignment（スキル整合）

このどちらかが落ちれば、評価は途中で停止し早期 reject の出力を返す。それ以上の分析でトークンを浪費しない。

高ウェイト次元:

• Seniority（シニア度）
• Compensation（報酬）
• Interview Likelihood（面接到達確率）

中ウェイト次元:

• Geography（地理）
• Company Stage（企業ステージ）
• Product-Market Fit
• Growth Trajectory（成長軌道）

低ウェイト次元:

• Timeline（タイムライン）

出力は数値スコア（1-5）と文字グレード（A-F）の組み合わせだ。Santiago によると、評価したオファーの 74% が 4.0 未満のスコアだった。システムなしでこの判定をしていたら、結局合わない求人を数百件も全文読むことに時間を溶かしていた、という意味だ。

このパターンが教える「評価系 Skill」の設計

10次元のフレームは求職評価に固有のものではない。「これをやるべきか？」を判断するシステム全般に転用できる。

1. 明示的なゲート で明らかに合わないケースを早期に切る
2. 重み付けされた次元 でトレードオフを正直に表現
3. 標準化された出力（数値+文字グレード）で下流のフィルタや集約に使える
4. キーワードマッチではなく推論ベース で文脈に適応する

これを投資判断、ベンダー選定、パートナーシップ判断、コンテンツ承認に適用すれば、場当たりの意見ではなく耐久性のある比較可能な判断系が作れる。

HITL：人間とエージェントの境界線

career-ops の中心的な設計原則が HITL（Human-In-The-Loop） だ。Santiago の言葉そのまま:

「AI がノイズをフィルタし、人間が判断する。」

エージェントは重い作業を担う。631 件の求人票を読み、パーソナライズしたレジュメを生成し、許可された場合のみフォームを送信する。ただし最終的なコミットは人間のレビューなしには行わない。

これは AGENTS.md 内の明示的なルールとして書かれている。

• 応募はユーザーレビューなしには絶対に提出しない。
• 4.0/5 未満のオファーへの応募は推奨しない（「速度より品質」）。
• オファーの生存確認は Playwright で行う（WebSearch は信頼できない）。
• 採用担当者の時間を尊重する — 50件の汎用応募より、5件の強いフィットを狙う。

HITL の哲学があるからこそ、このシステムは「実際に使える」。完全自動化は求職コンテキストではユーザーの評判を傷つけるし、完全手動だとシステム化の意味がない。

自分の Skills システムを設計するときの教訓は、最小限の人間チェックポイント を見つけることだ。判断を挟む最も小さい挿入点で、暴走的な自動化を防ぎつつ、速度のメリットの大部分を保てる。

テックスタック：トレンドではなく実用性

career-ops のツール選択は興味深い。

• Claude Code — エージェント的推論、コンテンツ生成、オーケストレーション
• Playwright — ポータルナビゲーションとフォーム入力のブラウザ自動化
• Puppeteer — PDF レンダリング（Playwright が一部の PDF を担当することも）
• Go — tracker 可視化のダッシュボード / TUI
• Node.js — ユーティリティスクリプト（merge-tracker、normalize-statuses、dedup-tracker）
• tmux — バッチ処理の並列セッション管理

特筆すべきは データベースの不在 だ。TSV ファイルと Markdown レポートを使う。Postgres も、Redis も、ベクトルストアもない。これは意図的で、システム全体がローカルで完結し、インフラ依存ゼロで動く。

帰結として:

1. ホスティングコストゼロ — どんなノートパソコンでも動く
2. データ主権の完全保持 — CV、評価、tracker は手元から出ない
3. フォークが容易 — 誰でもクローンしてカスタマイズして所有できる
4. 可搬性が高い — ディレクトリをコピーして npm install すれば動く

このスタック哲学（「ローカル、ファイルベース、MIT ライセンス」）が、システムが急速に普及した一因でもある。サインアップ壁もレートリミットもサブスクもない。「動くなら動く」だけ。

リポジトリの内側：CLAUDE.md / AGENTS.md 構成

career-ops を実際にクローンして気づくのは、CLAUDE.md がたった2行・83バイト であることだ。中身は実質これだけ。

@AGENTS.md

それだけ。CLAUDE.md は AGENTS.md へのポインタであり、実際の指示はすべて AGENTS.md に書かれている。

この設計が重要なのは、Claude Code / Codex CLI / マルチツール時代に対する明確な答えになっているからだ。AGENTS.md を真実のソースとして書き、CLAUDE.md でそれをエイリアスすることで、同じ指示が以下のすべてで動く:

• Claude Code（デフォルトで CLAUDE.md を読む）
• Codex CLI（デフォルトで AGENTS.md を読む）
• AGENTS.md 仕様を採用する将来の任意のエージェント CLI

ビルダーにとって、これは美しいパターンだ。AGENTS.md を真実のソースとして扱い、CLAUDE.md をそこに向けて、リポジトリがエージェント CLI エコシステム全体で重複なく動作する。

AGENTS.md の中身（実体の脳）

AGENTS.md は層化されたオンボーディング順序で構造化されている。

1. 二層分離ルール（重要）：User Layer（CV、profile、modes/_profile.md、tracker）は自動更新されない。System Layer（共有モード、スクリプト、テンプレート）は更新可能。カスタマイズは常に modes/_profile.md または config/profile.yml に配置し、modes/_shared.md には絶対に書かない。これにより更新がパーソナライゼーションを上書きしない。
2. オンボーディングゲート：評価実行前に cv.md、config/profile.yml、modes/_profile.md、portals.yml の存在を検証。欠けていればステップバイステップでセットアップを案内。
3. モード説明：14 モードそれぞれに1行説明とトリガー条件。
4. 品質と倫理ルール：自動送信禁止、低フィット応募の抑止、生存確認、採用担当者の時間尊重。
5. パイプライン管理ルール：3桁連番のレポート ID、バッチ tracker 追加、重複排除ワークフロー、正規状態マシン。
6. 言語サポート：デフォルト英語、modes/de/ modes/fr/ modes/ja/ でローカライズ語彙対応。

構造は典型的なエージェント指示ファイルよりはるかに詳細だ。「親切で正確に」と書かれた 200 行のテキストではなく、本番システムの運用ランブックそのものだ。

自分の Skills システムを構築するための学び

career-ops を「求職ツール」ではなく「設計の教科書」として読むと、再利用可能なパターンが見えてくる。

1. 主題ではなくトリガーで分解する

普通なら「評価」「ライティング」「自動化」のように主題で分解する。career-ops はトリガーコンテキストで分解した。ユーザーが今この瞬間に何をしているか？

• URL 貼り付け → auto-pipeline
• 企業リサーチ依頼 → deep
• パイプラインのレビュー → tracker

ユーザーは主題ではなくアクションで考える。トリガーベースの分解の方が直感的にハマる。

2. デフォルトの経路を最も楽にする

auto-pipeline がデフォルトのエンドツーエンドフロー。ユーザーは URL を貼るだけで、エージェントが全パイプライン（抽出 → 評価 → レポート → PDF → tracker）を追加プロンプトなしで回す。残り 13 モードは細かい制御が欲しいときの脱出ハッチ。

多くの自動化システムはこれが逆になっている。あらゆるステップをユーザーに指定させる。career-ops はデフォルト経路を最速にし、手動上書きをいつでも可能にする。

3. 品質ゲートを指示に埋め込む

ユーザーが良い判断をしてくれることを祈るのではなく、AGENTS.md は積極的に低品質な行動を抑止する。「4.0/5 未満のオファーへの応募は推奨しない」。これは柔らかい提案ではなく、エージェントがユーザーに伝える指示だ。

自分のシステムでは、ユーザーが低レバレッジな判断をしがちな箇所を特定し、エージェントに押し戻させる。

4. データベースが必須になるまでファイルを使う

career-ops は Markdown ファイルと TSV テーブルを使う。レポートは連番付きファイル。tracker は TSV。評価履歴はレポートのディレクトリ。

これによりシステム全体が検査可能、バージョン管理可能、diff 可能、可搬になる。データベースに切り替えた瞬間、これらすべてを失う。

5. オンボーディングをエージェントに組み込む

エージェントは任意の操作を実行する前に、必要なセットアップファイルの存在を検証する。なければ会話プロンプトで作成を案内する。別途のセットアップスクリプトやウィザードは不要だ。

6. ユーザーカスタマイズを慎重に層分け

二層分離（ユーザーファイル vs システムファイル、modes/_profile.md のような明示的なオーバーライド配置）が、システムが個人のカスタマイズを壊さずに更新できる仕組みだ。複数ユーザーが同じ Skills システムをフォークするときに最も必要なパターン。

7. 譲れないデフォルトとしてテックスタックを文書化

AGENTS.md はどのジョブにどのツールを使うかについて明示的だ。生存確認は Playwright、WebSearch ではない。PDF レンダリングは Puppeteer。並列セッションは tmux。正規ツールを指定することで、エージェントは選択にトークンを浪費しない。

今日から盗める7つのパターン

Skills を構築中で、具体的・転用可能なパターンが欲しいなら:

1. 二層ファイル分離（user/system）と明示的オーバーライド配置
2. トリガーベースのモード分解 — 1モード=1主要アクション
3. デフォルト・エンドツーエンド auto-pipeline とシングルモードの脱出ハッチ
4. 多次元の重み付けスコアリング と明示的なゲート通過基準
5. HITL チェックポイント — 人間判断の最小実行可能挿入点
6. ファイルベースの永続化（TSV、Markdown）— データベースではなく
7. AGENTS.md を真実のソース に、CLAUDE.md は @AGENTS.md でエイリアス

各パターンは career-ops から独立して取り出せる。リポジトリ全体をクローンしなくても恩恵を受けられる。

制約と隠れたコスト

このシステムにもトレードオフはある。

セットアップの複雑さは現実的だ。 5ステップのクイックスタートはあるが、archetype・スコアリング重み・tracker スキーマを自分の状況に合わせて完全カスタマイズするには有意な時間がかかる。本番品質の出力までは 2〜4 時間の前倒し作業を見込んでおく。

Playwright の依存は重い。 リポジトリをクローンして playwright install chromium を走らせると約 300MB 追加される。実際にブラウザ自動化が不要なら、Playwright 依存のモードはデッドウェイトになる。

モード作成自体が独自の規律を要する。 既存インフラに綺麗に統合される新モードを追加するには、ファイル規約、共有ルール、パーソナライゼーション層、tracker スキーマの理解が必要だ。「もう1個 Markdown 書くだけ」ではない。

ローカライゼーションは部分的だ。 ドイツ語、フランス語、日本語をサポートしているが、ローカライゼーションの深さは均一ではない。英語版と非英語版で機能の充実度が一致するとは限らない。

パイプラインは求職セマンティクスを前提にしている。 求職以外のドメインに一般化するには、oferta pdf apply とスコアリングフレームワークの大半を書き換える必要がある。アーキテクチャは転用できるが、プロンプトは転用できない。

これらは「使うべきでない理由」ではない。「どれだけの作業が必要か正直になるべき理由」だ。

よくある質問

関連記事