朝、GitHubを開いてCIの失敗を探し、レビュー待ちのPRを確認し、誰に返事をすべきかを整理する。コードを書く前の「確認して、次の一手を決める仕事」が重いチームに向けた道具が、Macアプリの Junior です。PRはコード変更の提案、CIは変更に対してテストやビルドを自動実行する仕組み。Juniorは、その周辺にある待ち仕事をAIへ渡す入口をまとめます。
v1.0.6では、ブランチへのpushや下書きPR作成などが承認カードなしで進む場合があります。作業を委任することと、変更を一切外へ出さないことは同じではありません。またMac上で動くアプリですが、ClaudeやCodexへ渡す内容はそれぞれのサービスへ送られます。本稿は公開仕様と一部の判定ロジックを確認した解説で、アプリ全体の安全性・日本語での作業成功率を実証したものではありません。
v1.0.6の公開は2026年10月24日14:35:34 UTC、日本時間では10月24日23:35:34。10月26日朝7時の調査基準で約31時間半です。旧名TriageからJuniorへの変更と、作業の渡し方・送信承認ルールの更新を中心に読み解きます。新しいLLMの発表ではありません。
今回の更新で、何が変わったのか
リリースノートでは、明示的に渡された仕事を扱う「Hand-offs」と、Needs you／With Junior／Waitingという状態を並べる新しいホームが案内されています。自分の判断が必要なもの、AIが進めているもの、相手を待っているものを分けて見る設計です。
| v1.0.6の差分 | 仕事での意味 |
|---|---|
| TriageからJuniorへ改名 | 既存データは初回起動で~/.triageから~/.juniorへ移行。保存済みブラウザーログインも移行対象 |
| PRの引き継ぎと読み取り中心の初回レビュー | 自分のPRではCI修正・レビューbot対応・rebaseなどを扱い、レビュー依頼にはまず読む段階を用意 |
| 送信ポリシーの統一と事前承認 | 従来のAutonomy段階を廃止。誰に・何を・いつ許可するかという事前承認とログを追加 |
| 新規ワークスペースの監視・定期ジョブはオフ | Settings → Automationsで必要な対象だけ有効にする |
| .junior/junior.mdによるリポジトリのルール | 保護対象のパス、必要な検査、レビュー担当などを記述。自動実行範囲を狭めるための設定 |
| 指摘から残すLearnings | AIが記録した作業上の学びを、人が採用・編集・取り消しできる |
rebaseは、作業ブランチを新しい基準のコミットへ載せ直す処理です。競合があれば解消が必要で、終わった後も検査が欠かせません。Juniorの「PRを見守る」は、通知を集めるだけでなく、許された範囲では変更も進める機能だと理解しておきます。
たとえば、小さな開発チームなら「自分が今日判断すべきPRを3件に絞り、理由と失敗ログの場所を出す」という使い方が考えられます。コード修正を最初から全面委任するより、判断材料を揃える仕事から効果を測りやすいでしょう。これは編集部の導入案であり、時間短縮の実測結果ではありません。
ローカルアプリとローカルLLMは違う：OS・料金・送信先
| 項目 | 確認できた条件 |
|---|---|
| Macアプリ | macOS 12以降。Apple SiliconとIntelを案内 |
| AIの準備 | 公式手順は、インストール・ログイン済みのClaude Codeを前提にする。Codexはチャット用の任意選択肢 |
| GitHub連携 | ログイン済みのgh（GitHub CLI）を利用。連携自体は任意 |
| 価格 | Junior本体はMITライセンスの無料OSS。AIは利用するClaude／Codex側の契約・利用量が別に必要 |
| データと通信 | ワークスペースのデータはMacの~/.juniorに保存。Claude、Codex、接続サービスへの送信は別に発生 |
| 日本語 | 日本語UIの正式対応や日本語での作業品質は今回未確認。後述の日本語指示文は試用案 |
| 常時稼働 | Macのスリープ中は動かない。ウィンドウを閉じてもバックグラウンドのサーバーは継続する設計 |
OS条件はMac版の説明と配布設定、費用・接続条件はREADMEで確認しました。公式は既存ログインを使う設計を説明していますが、Junior本体が無料であることを、AIの無制限利用やすべての契約での利用可という意味には広げません。組織の利用条件と、実際のログイン方式を確認して導入します。
ローカルLLMをMacに読み込んでオフライン推論するアプリとは異なります。「データベースが手元にある」「画面がMacアプリである」「AIへ送信しない」はそれぞれ別の性質です。コードやログをどのモデル・コネクターへ渡すかが、業務利用時の判断点になります。
公式READMEは、Macの再起動後に再開すること、実行できなかった定期ジョブをmissedとして記録することも説明しています。夜間処理を任せたい場合は、Macを閉じて眠らせる運用と両立するかを先に確かめます。
承認カードの境界：push・下書きPR・レビューを分けて考える
公式説明の「送信前に確認」という短い表現だけでは、実際の範囲を読み違えます。v1.0.6の変更履歴では、自分のブランチへのpushと下書きPR作成が例外です。さらにClaudeチャットの判定コードは、push先が既定ブランチでないかなどで判定しており、ブランチ名から人間の所有者まで検証するものではありません。 同じコードでは、Codexなどのチャットは変更ごとに確認するgated設定で扱われます。表の通常チャットの例外を、すべてのモデル接続へ一律に当てはめないでください。
| 操作・場面 | v1.0.6で確認した扱い | 導入時に見ること |
|---|---|---|
| 通常のClaudeチャットからのpush | 条件を満たす非既定ブランチへのpushは承認カードなし。mainなどへのpushや通常の強制pushは保留 | 他人と共有する作業ブランチも含め、送信先を人が確認 |
| 下書きPRの作成 | gh pr create --draftに該当する操作は例外として許可され得る | DraftでもGitHubへの送信。既存のCI設定により処理が動く可能性を確認 |
| 引き継いだPRの修正 | 指定したPRのheadブランチに限定。--force-with-leaseは許可、通常の--forceや別ブランチへのpushは拒否 | 通常チャットのルールとPRタスクの制約を混同しない |
| 対象のレビューbotスレッドへの返信・解決 | PRタスクの対象スレッドに対する操作は許可される場合がある | 「コメントはすべて都度承認」とは考えない |
| レビュー依頼の初回確認 | 読み取り専用のタスクではpush・レビュー投稿などの送信を拒否 | 読む段階と、レビューを投稿する段階を分ける |
| その他の送信 | 承認カードや事前承認の対象 | 事前承認を設定した仕事は毎回停止するとは限らない |
PRタスク側の細かい条件はtaskRunVerdictで確認できます。--force-with-leaseは、相手側のブランチが想定した状態かを確認してから履歴を書き換える方式で、通常の強制pushより確認が増えます。ただし、変更内容が正しいことまで保証するものではありません。
また、シェル操作は既定のルールとの照合で分類されます。承認画面を、あらゆる外部通信を遮断するネットワーク境界として扱うことはできません。読み取りだけで試すときは、依頼文に加えて、接続先の書き込み権限と読み取り専用タスクを選ぶことが大切です。
導入は1リポジトリ・1件のレビューから始める
アプリは開発初期のソフトウェアで、配布説明にはAppleの公証（notarization）未取得と記載されています。公証はAppleによる配布ソフトの確認の仕組みです。業務端末の導入ルールで許可されるかを確認し、公式インストーラーを読んだ上で公式手順を使ってください。本稿では保護機能を回避する操作は案内しません。
- 1まずMacのOSとClaude Codeのログインを確認する。GitHubを使う場合だけghの接続先アカウントとアクセス可能なリポジトリを確認する。
- 2導入が認められた端末で公式手順に従いJuniorを起動する。旧Triageから更新する場合は、移行前に必要なデータのバックアップを取る。
- 3新規ワークスペースのSettings → Automationsで、監視とジョブがオフになっていることを確認する。既存ワークスペースは新規の既定値を当てはめず、現在の設定を確認する。
- 4機密情報を含まない検証用リポジトリを1つに絞る。読み取り権限で接続できる構成を選び、レビュー依頼1件を読み取り専用の初回確認へ渡す。
- 5根拠のある指摘かを人が確認する。自動修正、定期監視、事前承認は、その結果と必要な権限を確かめてから段階的に追加する。
最初の成果物は、「今日直すべき箇所」と「判断に必要な情報が不足している箇所」を分けた短いメモで十分です。テスト失敗を見つけても、テストを消して成功にする提案では役に立ちません。失敗した検査名・ログの根拠・変更の関係まで説明できるかを見ます。
このレビュー依頼を読み取り専用で初回確認してください。対象は、いま開いている検証用リポジトリのPR 1件だけです。
コード変更、コミット、push、PR作成、コメント・レビュー投稿、マージ、外部への連絡、定期ジョブや事前承認の追加は行わないでください。
1. PRの目的を3行で要約する。2. CIの各結果を、検査名・状態・根拠URLで整理する。3. 変更箇所と関連しそうな失敗を示す。原因未確定ならそう書く。4. 人が次に確認すべきことを最大3件に絞る。5. 読めなかったログ・権限不足・未実施の検証を最後に分ける。
出力は日本語。事実と仮説を分け、コードの根拠はファイルと行で示してください。追加権限が必要なら実行せず、その理由を報告してください。日本語の依頼文をダウンロードできます。PR番号や対象は自分の検証環境に合わせてください。日本語で期待どおり回答するかも、最初の評価対象です。
何を測れば「導入する価値がある」と言えるか
| 測る項目 | 記録する内容 |
|---|---|
| 確認にかかった手間 | AIの処理時間と人が裏取りした時間を分け、従来の手順と比較 |
| 根拠の正確さ | 存在しないログ、古いコミット、別PRの結果が混ざらなかったか |
| 判断への有用性 | 次の行動を決められた項目数と、人が訂正した項目 |
| 操作範囲 | 依頼外の変更・送信がなかったか。承認ログとGitHub側の履歴も照合 |
| 利用量 | 1件の確認に消費したAI利用量。定期化すると何回繰り返すか |
件数を増やす前に、既知の軽いCI失敗と、ログの一部が読めないケースを1件ずつ用意すると比較しやすくなります。読めない時に原因を作り上げず「未確認」と返せるかが重要です。比較条件を揃えるため、使ったモデル、Juniorの版、PRのコミット、接続権限を記録します。
編集部の確認範囲：14件の判定テストと、未実測の部分
編集部はv1.0.6のソース（コミット58f762c）を固定し、通常チャットの承認判定テストとPRタスクの判定テストを実行しました。関連する純粋な判定関数をTypeScriptからJavaScriptへ変換し、Node.jsのテストランナーで14件すべて成功。通常のpush、既定ブランチへのpush、読み取り専用レビュー、対象botスレッドなどの分岐を確認したものです。文字列を判定するテストであり、実際のpushや投稿はしていません。
アプリのインストール・起動、Claude／Codexへの推論依頼、GitHubへの接続、通信監査は実施していません。したがって「PR修正を完遂できた」「送信を完全に防げた」「日本語レビューが正確だった」という製品実測ではありません。今回のテストで確かめたのは、限定した入力に対する判定ロジックと公式説明の対応です。
確認日：2026年10月26日（日本時間）。主な出典はv1.0.6のリリースノート、版を固定したREADME、本文中のソースコードです。レビュー対象を見渡す道具の使い分けは、Task Viewで変更箇所を整理する記事も参考になります。