---
title: "セッションに見えるもの"
description: "「セッションに見えるもの」：yokoten ガイドの一章。"
canonical: https://yokoten.app/ja/docs/guide/what-a-session-sees
lang: ja
source: https://github.com/yokoten-labs/yokoten/blob/v0.1.2/docs/i18n/ja/guide.md
ref: "v0.1.2"
---

> For AI agents: the documentation index is at https://yokoten.app/llms.txt. To set up yokoten in a project, follow https://yokoten.app/agents.md.

# セッションに見えるもの

まだ yokoten を導入していないプロジェクトで、セッションの始めにはこう出ます。

```
yokoten: stage 1 of 5, safety net

  Next      No AGENTS.md, so the agents have no written rules here.

  Why       An agent follows the rules it can read, and only those.

  Fix       `yokoten init`

Tell the user in plain words, one step at a time, and offer to do it (as-is,
lighter, or not now with a reason).

yokoten: ~/.config/yokoten/private-marks is missing or has no marks

  Why       Without your marks, the privacy check knows only email addresses, IP
            addresses and secrets.

  Fix       `yokoten marks add`, then type your name, your city or a domain; it
            is not shown.

  More      https://github.com/yokoten-labs/yokoten/blob/main/docs/guide.md#privacy
```

セッションが聞くのは一つのステップだけです。関所、次のステップ、そしてそれがなぜ大事かです。二つ目のブロックは非公開の印についてで、印がまだ一つも保存されていないときだけ出ます。関所は毎回ファイルから計算され、何も保存されません。「今はしない」と印を付けたステップは飛ばします。順番は助言です。後のステップを先に終えても、終わったものと数えます。すべてのステップが終わったか「今はしない」になると、セッションはそう伝える一行を聞きます。ここにないのに既定ブランチにはあるファイルは、`init` ではなく、そのブランチの名前で示します。Claude Code がコンテキストを圧縮したあとは、セッションは変わった注意だけを聞きます。各セッションは聞いた内容を `~/.config/yokoten/sessions/` に保ち、7 日より古いファイルは消します。エージェントはあなたの言語で伝えます。yokoten は英語を出力します。エージェントが最も確実に読む言語だからです。

`yokoten doctor` は道の全体を示します。各ステップは **done**、**next**、**to do**、**not now**（あなたの理由つき）、**can't check** のどれかです。yokoten がまだチェックできないステップは一覧に出ません。

| 関所 | ステップ |
|---|---|
| **1 · 安全網** | `rules`、`tool-hook`、`commit-check`、`runtime`、`tests`（テストのコマンドがあり、CI がそれを走らせる） |
| **2 · issue とプルリクエスト** | `remote`（リポジトリがコードホストにあり、そこからブランチが push されている）、`ci`（CI が `check` を走らせるか、yokoten Action を使う）、`issues`（todo ファイルがない）、`templates`、`labels`（標準の一式）、`milestone`（開いているもの）、`no-build-output`（`dist/`、`build/`、`out/` に何もなく、ビルド済みバイナリもない） |
| **3 · リリース** | `changelog`、`titles`（CI が `check --pr` を走らせるか、`pr-check: false` なしでプルリクエストに Action を使う） |
| **4 · エージェントのチーム** | `codeowners`、`bot`、`skills`、`sandbox`（各エージェントはワークツリーに書け、それより広くは書けない）、`review`（既定ブランチへのマージに承認が一つ必要） |
| **5 · 公開** | `security-files`（セキュリティポリシー、Dependabot、ライセンス）、`protection`（既定ブランチと `v*` タグのルールセット）、`merge-settings`（squash のみ、マージ時にブランチ削除）、`security-settings`（秘密のスキャン、push の保護、非公開での報告、Dependabot の警告） |

最後の三つはサーバーの設定です。完全な `doctor` は `gh api` で読み、読むだけです。`gh`、サインイン、ネットワーク、GitHub のリモートがないときは、**can't check** であり、done にはなりません。セッションはネットワークを決して呼ばないので、そこでは常に **can't check** です。

**別のホスト。** doctor はホストを `origin` リモートから読みます。GitHub では上のとおりサーバーを読みます。Gitea では、`yokoten.json` にホストを書いて（`"host": "gitea"`）、bot ユーザーのトークンを `GITEA_TOKEN` に入れます。すると doctor は Gitea の API で、ブランチとタグの保護、ラベル、マイルストーン、忘れられたブランチを読みます。`gitea.com` はキーなしで分かります。GitLab など別のホストでも、中核は同じに動きます。ルール、番人、コミットチェックです。ホストだけが判断できるステップは、`tests`、`ci`、`labels`、`milestone`、`titles`、`codeowners`、`bot`、`review` と、サーバーの三つのステップです。そこではどれも **can't check** になり、何を尋ねるかを言うので、手で設定できます。それらが関所を止めることはありません。自前のサーバーの名前は決して出力しません。doctor は「このホスト」と呼びます。

関所 2 の `labels` と `milestone` も同じように読みます。標準のラベルは `bug`、`feat`、`docs`、`refactor`、`ci`、`owner`、`incident`、`good first issue`、`hotfix`、`security` と、ティアのラベル `tier A`、`tier B`、`tier C` です。`init` は足りないものを示し、`init --github --yes` が追加します。

関所 4 の `review` も同じようにサーバーを読みます。既定ブランチのルールセット、またはブランチ保護が、承認レビューを一つ以上求めていれば done です。GitHub では自分のプルリクエストを自分で承認できません。だからボットがプルリクエストを開き、あなたが承認してマージします。設定するには、既定ブランチのルールセットを編集します。「Require a pull request」で「Required approvals」を 1 にします。また、Settings、Actions、General で「Allow GitHub Actions to create and approve pull requests」をオフにしておきます。オンだと、ボットが push したワークフローがボット自身のプルリクエストを承認できるので、`review` は done になりません。そうすれば OpenSSF Scorecard は、各変更をレビュー済みと数えるはずです。マージした人が書いた人ではないからです。これは Scorecard の文書で読みましたが、実際の Scorecard の実行ではまだ確かめていません。無料プランの非公開リポジトリにはルールセットがないので、そこでは `review` は **can't check** になり、リポジトリが公開される関所 5 を待ちます。**not now** ではありません。その印は、あなたがする決断にだけ使います。

`init --github --yes` は、`yokoten.json` の「areas」にあるあなたの領域も、一つの灰色でラベルに追加します。8 領域以下のときだけです。それより長い一覧は雑音なので、使う少数を手で作ってください。すでにある領域のラベルはそのまま保ち、yokoten は決して削除しません。

ボードは任意です。`init --github --yes --board` は、リポジトリの名前のボードを作り、リンクします。その Status フィールドには Todo、In progress、In review、Done が入ります。ボードには gh トークンの `project` スコープが必要です。ないときは init はボードを飛ばし、`gh auth refresh -s project` を実行するよう伝えます。二回目の実行はタイトルでボードを見つけ、何も作りません。API ではボードのビューやワークフローを設定できません。だからボードがリンクされていると、完全な `doctor` はそれらを「手で」の行として一覧します。それらが doctor を失敗させることはありません。

ステップのあと、`yokoten doctor` は、あれば満たしている外部標準を名指しします。たとえば `ci (Scorecard: CI-Tests)` です。セッションのメッセージには出しません。

[記録 0004](https://github.com/yokoten-labs/yokoten/blob/v0.1.2/docs/records/0004-the-road.md) が、なぜ道がこうなっているかを書いています。

このリポジトリも同じ道を歩いているので、各関所が動くのを見られます。

| 関所 | 学べること | ここで見る |
|---|---|---|
| **1 · 安全網** | エージェントが読むルールと、ルールで足りないときに止めるチェック | [AGENTS.md](https://github.com/yokoten-labs/yokoten/blob/v0.1.2/AGENTS.md) |
| **2 · issue とプルリクエスト** | すべての変更は issue として始まり、CI が通ったときだけマージされる。ラベル、マイルストーン、ボードがそれを保つ | [issue](https://github.com/yokoten-labs/yokoten/issues?q=is%3Aissue)、[プルリクエスト](https://github.com/yokoten-labs/yokoten/pulls?q=is%3Apr)、[ボード](https://github.com/orgs/yokoten-labs/projects/1) |
| **3 · リリース** | 何がなぜ変わったかを言うコミットメッセージ、変更履歴、リリースごとのバージョン番号 | [CHANGELOG.md](https://github.com/yokoten-labs/yokoten/blob/v0.1.2/CHANGELOG.md) |
| **4 · エージェントのチーム** | ボットがプルリクエストを開き、ワーカーがタスクを受け、レビュアーが確認する。マージするのはあなただけ | [エージェントをチームのように動かす](https://yokoten.app/ja/docs/guide/managing-agents-like-a-team.md) |
| **5 · 公開** | 過去のすべてのコミットを個人情報について調べ、セキュリティ設定を入れ、`main` を守る | [セキュリティポリシー](https://github.com/yokoten-labs/yokoten/blob/v0.1.2/.github/SECURITY.md) |

そして、エージェントがリリースのタグを push しようとすると、こう出ます。

```
yokoten stopped this: git push --tags pushes tags [release]

  Why       Only the owner decides when to release.

  Instead   Stop and tell the owner: only the owner releases, with the steps in
            How to release; do not look for another way.

  More      https://github.com/yokoten-labs/yokoten/blob/main/docs/guide.md#how-to-release
```

直し方はどのエージェントでも同じです。エージェントに止まってオーナーにリリースを任せるよう伝えます。
リリースの承認の方法と、各エージェントを始めるコマンドは、英語ガイドの
[How to release](https://github.com/yokoten-labs/yokoten/blob/main/docs/guide.md#how-to-release)にあります。
Muse Code と OpenCode は変数をフックに渡すか分かっていないので、オーナーはその外でリリースします。
Gemini CLI の厳しい環境の消毒がオンのときは変数が落ち、オーナーは Gemini CLI の外でリリースします。

どの拒否も同じ四つの部分を持ちます。最初の行は何が起きたか（**what**）で、最後は `yokoten stopped this: <what> [<id>]` の形でルールの id が角括弧で付きます。**Why** の行はなぜ大事かを伝えます。**Instead** の行は直し方（コマンドか編集）です。**More** の行は、ルールの完全な説明へのリンクです。ファイルの問題では、場所がタイトルのすぐ後に来ます：`yokoten stopped this: file:line: <what> [<id>]`。見つけたものは種類だけを名指しし、そのもの自体は決して出しません。秘密情報や個人情報の印は決して出力しません。

ルールがなぜあるかを聞くには、`yokoten explain <id>` を実行します。id はルールかステップの名前で、たとえば `secret` や `commit-check` です。id なし、または知らない id なら、すべての id を一覧します。

```
$ yokoten explain force-push
force-push: no plain force push (core rule 7).
Why: a plain force push can throw away work that someone else pushed.
Check: the tool-call guard stops `git push --force`, `-f` and a `+ref`; `--force-with-lease` passes; a branch ruleset on the server is the lock.
Docs: https://github.com/yokoten-labs/yokoten/blob/main/docs/guide.md#the-core-rules
```

## このマシンだけで作業する

停電、クラッシュ、壊れたディスクは、一つのマシンだけにある作業を失わせます。だから `doctor` はその作業を一覧し、各項目に、それを救う一つのコマンドを付けます。

| 注意 | 意味 | コマンド |
|---|---|---|
| `uncommitted-changes` | ワークツリーに変更されたファイルがある。いくつか、一番古いものはどれくらい前か | そこで `git add -A` と `git commit -m "chore: save work"` を実行し、push する。`.yokoten/` があるときはメッセージを `chore: add yokoten` にし、その複製をコミットすることが目的になる |
| `unpushed-commits` | ブランチに、どのリモートにもないコミットがある。または切り離された HEAD に、どのブランチにもないコミットがある | `git push`、上流のないブランチなら `git push -u origin <branch>`。切り離された HEAD なら先に `git switch -c <name>` |
| `stashes` | stash がある。stash は決して push されない | `git stash branch <name>` を実行し、そのブランチを push する |
| `stale-index-lock` | クラッシュで `index.lock` が残っていて、リポジトリで git のプロセスが走っていない | そのファイルを `rm` する |
| `repo-on-tmpfs` | リポジトリが tmpfs 上にあり、再起動で空になる | `git push --all origin` を実行し、長持ちするフォルダにもう一度 clone する |
| `repo-in-temp-folder` | リポジトリが一時フォルダの下にあり、システムが再起動で空にすることがある | `git push --all origin` を実行し、長持ちするフォルダにもう一度 clone する |
| `finished-worktree` | 変更のないワークツリーで、ブランチがマージ済みか、上流が消えているか、切り離された HEAD が既定ブランチにある | `git worktree remove <path>`。ブランチは残る |
| `missing-worktree` | git がまだ一覧するワークツリーのフォルダが消えている | `git worktree prune` |

push されていないコミットは、まだこのマシンだけにあります。`origin/main` から作ったブランチはそれを追うので、そのコミットは自分のブランチへ行き、main へは決して行きません。

squash マージはブランチの履歴に印を残しません。だから上流が消えたブランチもマージ済みと数えます。変更のないワークツリーを、削除して安全とは決して言いません。作られてから動いていないブランチや切り離された HEAD は、マージ済みとは言いません。新しいのです。

`index.lock` について、doctor はリポジトリで作業する git のプロセスを探します。Linux では各プロセスのフォルダを読みます。macOS と Windows では読めないので、git のプロセスがあれば「分からない」とします。すると doctor はそのファイルを消すよう決して言いません。資格情報のキャッシュなど、git の長く走る補助プロセスは数えません。tmpfs のチェックは `/proc/mounts` を読むので、Linux でだけ走ります。

一時フォルダは、システム自身のもの（`TMPDIR`、Windows では `%TEMP%`）と `/tmp` です。WSL は再起動で `/tmp` を空にします。tmpfs でなくてもです。ほかのフォルダを調べるには、`YOKOTEN_TEMP_DIRS` に一覧します。区切りは `PATH` と同じです。空にするとチェックを切ります。

そのようなフォルダにあるリポジトリ自体には、常に注意が出ます。設定の問題だからです。そこのワークツリーは、危険にある作業を持つときだけ名指しされ、その作業自身の注意の中で示されます。たとえば「../w has 3 uncommitted files, the oldest changed 2 days ago, and is under the temp folder (/tmp), which the system may empty on restart」です。危険なものを持たないワークツリーは、完全な `doctor` で件数つきの一行になり、セッションでは何も出ません。各直し方は、ワークツリーを `.worktrees/` の下に作り、一時フォルダの下には作らないよう伝えます。

これらはすべて注意です。`doctor` を失敗させることはありません。doctor はここでは読むだけです。ファイルも ref もワークツリーも変えず、git は任意ロックを切って走ります。パスはリポジトリからの相対、または `~` から示します。

セッションが聞くのは、危険にあるものだけです。多くても三つです。コミットされていない変更は、一番古いものが一時間たってから初めて聞きます。今進んでいる作業は忘れられないからです。片付けるワークツリーは完全な `doctor` に任せます。一時フォルダの二つ以上のワークツリーが危険な作業を持つときは、最初に件数の一行を出します。

セッションはこれに多くても一秒しか使いません。セッションが冷たいディスクを待ってはいけないからです。時間が来ると、読んだものを見せて「doctor stopped early」と言います。完全な `doctor` に時間の制限はありません。

---

前の章: [三つのチェックと一つの錠](https://yokoten.app/ja/docs/guide/three-checks-and-a-lock.md)
次の章: [四つの層](https://yokoten.app/ja/docs/guide/four-layers.md)