AIの記憶のしくみと、
第二の脳のつくり方

はじめに

全体像 — これから作る「完成形」と4つのステップ

細かい説明に入る前に、これから何を作るのか（ゴール）とどんな順番で作るのかを先に見ておきます。ここが全体の地図です。

図｜第二の脳の「お手本の型」（完成形）— コーポレート(.claude)と事業部(dev)、上げる/上げないの3ルール

完全版 — 実際の粒度での完成形（「どのCLAUDE.mdの話？」で迷子にならない地図）

上の型は簡略版です。実際には同じ名前のファイルが複数の場所に登場するため、ここで一度、端折らずに全部書きます。以降の章や他の教材で迷ったら、この図に戻ってきてください。

図｜完全版の完成形 — 同名ファイルの場所と、GitHubとの対応を端折らず全部

とくに混同しやすい「同じ名前・似た名前で別物」はこれだけあります。中身の例で覚えるのが早いです：

AIが読む順番 — チャットを開始した瞬間に何が起きるか

図｜AIが読む順番 — 自動は「ルール①→ルール②→記憶の目次」の3つだけ。残りは必要な時にAIが開く

NotionやGoogle Driveと何が違う？ — この仕組みの立ち位置（比較と併用）

「ナレッジならNotionやDriveでもいいのでは？」への答えを先に。原則は情報は、発生した場所の近くに正本を置く——AIを使うほど自然に溜まる情報（AIの記憶・スキル・プロジェクトの決まりごと）はこの仕組みへ、業務データ（顧客管理・議事録など）は業務ツールへ。役割が違うので、対立ではなく分担です。

作る順番は4ステップ（上から順でOK）

この地図を、次の4つのステップで一つずつ埋めていきます。各ステップの頭に区切り（緑の帯）を置いてあるので、今どこを作っているか迷いません。

※①〜③までで「第二の脳」は完成します。④は本物の鍵（APIキー等）を扱い始めてから足す“強化”パートなので、最初は無理にやらなくてOKです。

第1章

記憶の正体 — ただのテキストファイル

Claude Codeの「メモリ（記憶）」は、特別な仕組みでも、AIの脳内でもありません。PCのフォルダに入った、ただの文章ファイルです。だから自分の目で開けるし、直せるし、消せます。

※混同注意——Claudeのアプリ側（チャット・Cowork）にも「メモリ」があり、名前は同じでも別の仕組みです。あちらはAnthropicのサーバー側に保存され、設定 > メモリから中身を確認・編集・削除します（2026年8月25日の更新でチャットとCowork〈クラウド実行〉の間で共有されるようになりました）。この教材で扱うClaude Codeの記憶は、あなたのPCの中の.mdファイル——クラウドや他のパソコンとは共有されません（公式に明記）。だからこそ、自分でバックアップを取る必要があるのがこの先の話です。

まず「.md」とは何か

ファイル名の末尾につく「種類ラベル」（拡張子）です。見慣れたものと同じ仕組み：

フォルダとファイルの関係（最重要の基礎）

フォルダ＝入れ物（箱）、ファイル＝中身そのもの。ファイルの中にファイルは入れられません。記憶フォルダの中身はこうなっています：

図1｜フォルダの中身 — メモの紙が並んでいるだけ

図2｜そのうち1枚（MEMORY.md）の中身 — ただの箇条書き

図2の各行はただの文字です。ファイル名を「文字として」書いてあるだけで、ファイル本体は図1のとおり隣に並んでいます。

「MEMORY.md」だけは特別な1枚

62枚のメモは全部が対等ではありません。「MEMORY.md」という名前のファイルだけは特別で、Claude Codeにはチャットを始めるたびに、この1枚を必ず最初に読むという決まりがあります。中身は図2のとおり「どのメモに何が書いてあるか」の一覧＝受付案内（索引）。

AIはまずこの案内を読み、今の話題に関係するメモ（.md）だけを本棚（memoryフォルダ）から選んで開きます。残りの何十枚は、案内を見て必要になったときだけ開かれる——つまりMEMORY.mdは「どのファイルを読むべきかを教えるメモ」です。

読み込みは「二段構え」— だから燃費がいい

AIは新しいチャットを始めるたびに目次（索引）だけを自動で読み、話題に関係するメモの本文だけをその都度開きます。

この設計のおかげで、メモが増えても毎回のコスト（トークン＝AIの読み書き量）はほぼ一定に保てます。しかも、この「目次に整理する」作業は、基本Claude Codeが自動でやってくれます（下の①②は"自動の動き"）。人が気にかけるのは、放っておくと"死んだメモ"が混ざる③の「点検」だけ、と考えてOKです：

第2章

2種類の記録 — AIの手帳と、現場の作業ファイル

「メモリ」と「各プロジェクトフォルダの中の記録」は役割がまったく違います。

実例：テンプレ販売の場合、メモリ側には「商品化が進行中。詳細はリポジトリのPRODUCT_PLAN.mdを必ず確認」と書いてあります。つまりメモリは場所を指す付箋で、本体は現場（プロジェクトフォルダ）にある。新しいチャットで「あの件の続きやろう」と言われたAIは、まず手帳（付箋）で思い出し、現場のファイル（本体）を開いて作業する——という流れです。

※もう1つ「CLAUDE.md」という記録もあります。これはあなたが書くルール（職場に貼る就業規則のようなもの）。メモリはAIが書く記録。どちらもただの.mdです。CLAUDE.mdの置き場所は2段——全案件で効かせたい普遍ルールは`~/.claude/CLAUDE.md`（＝コーポレートの社則・どこでも効く）、その案件だけのルールは各プロジェクトの`CLAUDE.md`（＝現場ルール）。一部だけ共有したい時は各プロジェクトから@importで共通ファイルを読み込む。なおCLAUDE.mdは公式が「200行未満」を目安としており、打ち切りではなく長いほど毎回の読み込み量を食い、指示の守られ方が落ちるという推奨（ハード上限は4MiBで通常は届かない）。⚠️よく混同されるが、「200行 または 25KB で打ち切り」はCLAUDE.mdではなくメモリの目次ファイル（MEMORY.md）の上限（公式に「この上限はMEMORY.mdにのみ適用される」と明記）。長くなったら、詳細は別ファイルに出して本体には「◯◯の時は△△.mdを読む」と一言リンクだけ書くと薄く保てる（＝MEMORY.mdの索引と同じ考え方・必要な時だけ読まれる）。作業手順ならスキルに出すのがいちばん効く——スキルは起動時に説明文だけが読まれ、手順の本文は呼ばれたときにしか読まれないので、何十個作っても毎回のコストはほぼ増えない（→ skills.html）。@importは共有・重複排除用で、中身は毎回読み込まれる点だけ別物。なお@importはClaude Code専用の記法（他のAIでは効かずただの文字列）。Codex等でも同じリポを使うなら、①の"普通の文章ポインタ"の方がツール非依存で安全。

まとめ：3層で覚える — ルール・記録・記憶

ここまでの登場人物は、この3層で整理すると迷いません：

※「大事なことはmemoryだけに任せず.mdへ」と「memoryもバックアップする」は矛盾しません——前者は資産化（チームに残す）、後者は保険（自分の手帳を守る）で、役割が別です。

第3章

置き場所の設計 — コーポレートと事業部に分ける

記憶フォルダは C:\dev\（作業場）の中ではなく、C:\Users\<ユーザー名>\.claude\ にあります。これは意図的な分離です。

なぜ全部 dev の下にせず、.claude に分けるのか（シンプルに）

一言でいうと 「コーポレート（会社全体の共通資産・社則）と、各事業部（現場ごとの実務）を分ける」のと同じです。

分ける理由は3つ：

1. そもそもClaude Codeがそういう作り：~/.claude はClaude自身の「家」で、どのフォルダから起動しても必ず最初に読む。だから"どこでも効いてほしい共通のもの"の指定席がここ。
2. 巻き添え事故を防ぐ：プロジェクトは増減・引っ越しする。記憶をその中に置くと消した瞬間に頭脳ごと消える。分ければ作業場をいくら片付けても頭脳は無傷。
3. 効く範囲（スコープ）で仕分けできる：~/.claude＝全案件に効く（日本語で返答・.env禁止）／各プロジェクト＝その案件だけ。置き場所を変えるだけで"全体ルール"と"案件ルール"が自然に分かれる。

混ぜると事故ります：「プロジェクトごと消したらAIの記憶も消えた」「制作物のリポジトリにAIの設定が紛れ込んだ」。成果物と道具は別の場所——これが原則です。

→ この「コーポレート（.claude）／事業部（dev）」の分け方は、冒頭の「お手本の型」の図の上半分・下半分にそのまま対応しています。

第4章

ノートを1冊にする — 記憶の一本化

仕様：記憶は「起動フォルダごと」に別ノート

Claude Codeは「どのフォルダで起動したか」を仕事の単位とみなし、フォルダごとに別々の記憶ノートを作ります。起動フォルダのパスがそのままノートの名前になります：

エンジニアには合理的です（A社案件の記憶をB社案件に持ち込まない）。しかし個人が自分の事業で使うと、起動フォルダは日によって変わるので——「昨日教えたのに、今日は忘れてる」が起きます。忘れたのではなく、別のノートに書いてあるだけ。

解決策：設定1行で「ノートは1冊」

C:\Users\<ユーザー名>\.claude\settings.json に1行足すだけです：

意味は「どこで起動しても、記憶はこの1か所に書け」。実際、私たちの環境でも記憶が3か所に散らばりかけたため、この設定で一本化しました。すでに散らばっている場合は、各フォルダの.mdを集約先に移せばOK（AIに頼めばやってくれます）。

第5章

消えない仕組み — GitHubバックアップ

原則：「PCの外にコピーが1つ」あれば防災は成立

「PCが壊れたら終わる」問題の解決策は、場所を変えることではなくPCの外に複製を持つこと。その置き場としてGitHub（Privateリポジトリ・無料）を使います。記憶フォルダ自体がGitの管理下にあり、「プッシュ」すればGitHubに写しが送られます。

GitHubが同期サービスより強い理由：履歴

同期（Obsidian SyncやiCloud）は「今の状態」を写すだけなので、誤削除も同期されます。GitHubは履歴が全部残るので、3年前の状態にも戻れる。だから掃除（メモの削除）を気軽にやれる——消しても戻せるからです。

「ロックイン」を避ける＝乗り換え自由でいる

ロックインとは、データがそのサービス専用の形になって離れられなくなること。数百ページ貯めた後では引っ越しが大仕事になり、値上げや仕様変更に従うしかない立場になります。ChatGPTやClaudeアプリ内蔵の「メモリ機能」も同じで、中身を持ち出せないので正本にしてはいけません。

逆にMarkdownの記憶は他のAIにもそのまま引き継げます。たとえばCodexなら設定ファイル（AGENTS.md）に「最初にこの索引を読め」と1行書くだけ。中身（資産）は持ち運べて、仕組み（自動読み込み）だけツールごとに1行設定する——これが「正本はMarkdown」の実利です。

「どのAIでも使える」と「Claude Code専用」の切り分け

覚え方は一言：「中身（資産）はどのAIでも・自動で読む仕組みはツールごと」。

＝乗り換え・併用しても資産はゼロ円で持ち運べる。ツールを変えたら「自動で読ませる1行設定」だけをやり直す。

第6章

保存先の使い分け地図

判定は1問：「AIに管理・編集までさせたいか」

直感的な言い換え：「これは資料か、自分の脳の一部か」。資料はDrive、脳の一部はGitHubへ。今Driveで回っているもの（議事録など）は引っ越し不要です——AIはDriveも読めるので。

「GitHubを Drive 代わりにできる？」— 大物はNG

GitHubはテキストなら実質無制限。だから「動画やデザインもここに置けば？」と思いがちですが、大きいファイルには向きません。理由は仕組みにあります。

つまりテキストの"脳"はGitHub、大物の"倉庫"はDrive。1つにまとめようとせず、役割で分けるのが正解です。

100MB上限の目安：Markdownメモ＝数千〜数万本／スクショPNG＝30〜200枚／スライドPDF＝5〜50個／音声1分＝約1MB／動画は1分ほどで上限超え（文字は無限・画像OK・音声ギリギリ・動画は一発アウト）。※「1GB推奨」等は1リポジトリごとで、アカウント全体に上限はなく、リポジトリは無制限に作れる。なお公開/非公開は選べ、メモは必ずPrivate（Public＝オープンソースは"世界に公開する"意図的な選択で、企業やSaaSの製品コードは大多数がPrivate）。

NotebookLMとの仕組みの違い（RAGとまるごと読み）

メモ数千ファイル程度まではClaude Code方式で十分。個人の第二の脳の規模でRAGの出番はまずありません。

表・数字データはどうする？

Obsidianの正しい位置づけ

Obsidianは「保存場所」ではなく閲覧・執筆アプリです。GitHub＝倉庫（保管と履歴）、Obsidian＝机（同じフォルダを快適に読み書きするメガネ）——競合せず、併用できます。AIに読み書きさせるだけなら不要。「自分の目で眺めたい・つながりを地図で見たい」と思った日に、今のフォルダを指定して入れるだけです。

大物を"脳"につなぐ — 栞（しおり）テク

PDF・パワポ・エクセル・動画は、AIが中身を読みにくく、検索にも引っかからず、リンクも付けられない——せっかくの資料が"脳の外"に取り残されます。そこで、その資料1つにつきMarkdownを1枚だけ添える。中身は「要約＋タグ＋元ファイルへのリンク」。これだけ。

位置づけは「大物はDriveに置き、GitHubには栞（テキストの目印）だけ残す」——上の"テキストの脳＝GitHub／大物＝Drive"の橋渡しです。環境をいじる必要はゼロ、遡って全部やる必要もない。「AIに見つけてほしい大事な資料が出てきた時だけ」1枚添えるで十分。

さらに上級（必要になったら足す2つ）

土台（GitHub＋Markdown＋索引）だけで第二の脳は十分に成立します。以下はFOMOで積み上げないのがプロの運用——複雑さと事故リスクを足すからです。

今の数十〜数百メモの規模では、手入れした索引（MEMORY.md）方式の方がむしろ制御が効いて優秀。足すなら栞テクだけが"今すぐ"価値が高い（環境変更ゼロ）。

第7章

毎日の運用 — 第二の脳を育てる

入力・保存・転記の役割分担

頻度は流量次第。週1の定期作業は流量が増えてからで、最初は「溜まったなと思ったとき」のトリガー式で十分です。仕組みを作りすぎないこと。

「ほぼ放置」でも回る理由 — 覚えておくことをゼロにする

掃除・転記・バックアップを「あなたが覚えておく作業」にしないのがコツ。中でもバックアップは"手でプッシュし忘れる"のが唯一にして最大の穴です。ここを自動化すれば、第二の脳は本当に放置で守られます。土台は「AIに読ませられる開いた形式で貯め続ける習慣」——道具選びより、この習慣が本体です。

バックアップの自動化 — OSのスケジューラに任せる

やることは「メモに変更があれば自動でGitHubへ送る」だけ。これをOSの定期実行機能（Windowsはタスクスケジューラ／Macはlaunchd／Linuxはcron）に、小さなスクリプトを登録して任せます。肝はアプリを1つも開いていなくてもOSが実行すること。ノートアプリ（Obsidian等）のプラグインは"そのアプリを開いている間だけ"なので、放置には向きません。

OS cron と AI cron — 「判断が要るか」で使い分ける

定期実行には2種類あり、混同しがちです。線引きはシンプル：

だからバックアップはOSのスケジューラ、AIニュース日次ダイジェストのような頭を使う自動化はAIのcron。同じ理由でコードは手動コミット（意味ある単位で・壊れた状態を上げない）／メモはタイマー自動——この分け方は「自動対象のフォルダにメモだけを入れ、コードは入れない」だけで実現します。

※この仕組みづくり自体が、講座の最初の課題としても機能します。「作りたいものがまだ無い」人でも、全員に確実に資産が残り、以降どのメモアプリを使っていても「いつでもClaude Codeで呼び出せる状態」になるからです。

第8章

APIキーの守り方 — 3つの別々の問い

「サーバーに鍵が行くのが気になる度」と「Bitwardenを使うか」は、実は別々の軸です。混ぜると混乱するので、APIキーの守りは3つの独立した問いに分けて考えます。

問い0：全員・無条件の最低ライン（土台）

下のどれを選んでも必ずやる共通の土台。ここだけで実際の事故の大半（GitHub流出・画面への映り込み）を防げます。①gitに上げない（.gitignore）／②チャットに鍵を貼らない／③従量課金の鍵は使用上限・予算アラート／④画面録画・共有に映さない。

問い1：AI（チャット→サーバー）に鍵を"見せる"か？

AIに見せた物はサーバーを通ります（第5章）。それをどう扱うか：

問い2：鍵を"どこに保管"するか？（問い1とは別の軸）

3つは直交している（自由に組み合わせられる）

問い1（見せる/見せない）と問い2（ローカル/金庫）は独立。掛け合わせの4象限：

第9章

deny封印のしくみ — AIに秘密を読ませない

第8章「問い1」の"厳しめ版"を、もう一段だけ詳しく。deny（ディナイ）は、AIに .env などの秘密ファイルを読ませないための、一番強い設定です。

権限は3階層。denyは最強の壁

denyの決定的な点：会話中に「OK」と言っても覆せない。手動承認より上位の、絶対的な壁です。

どこに書くか

書き方の読み方

何を止めて、何を止めないか（核心）

だから動画生成などの自動化はそのまま動く。止まるのは「AIが覗く」動作だけ。秘密でない設定は config に逃がしてあるので、AIも困りません。

足す行（既存は消さず追記）

いつ・どう設定するか（手順）

denyは"全員が初日にやること"ではありません。「守るべき鍵を実際に扱い始めた段階」で導入します。最初から全員に課すと難しくて詰まるので、下の合図が出るまではラク版（AIが.envを読める）のまま学ぶのがコツ。

事前準備（封印前に3点チェック）

設定はAIに頼むのが一番かんたん（コピペ可）

確認：AIに「うちの.envを読んでみて」と頼み、「ブロックされる／読めない」と返ればOK。反映されなければ Claude Code を再起動。

※念のため、作業フォルダの外（デスクトップなど）にダミーの .env を作って読ませてみると、// が効いているか確かめられます。読めてしまう場合は先頭の // が抜けています。

第10章

キーの通り道 — マスターから実行まで

APIキーを金庫（Bitwarden等）に移すと「キーは金庫だけにある」と思いがちですが、正確には2か所にあります。ここを誤解すると、片方を消して自動化を壊します。

2つの層（マスターと実働コピー）

流れ

だから「渡し方」は今までと同じ.envに直書き。変わるのは調べる場所が .txt から Bitwarden になるだけ。新しい習慣は「新規／更新のとき、値をBitwardenからコピーして .env に貼る」1つだけです。

まとめ

全部を合わせた実例 — 私のPCとGitHubの全体図

ここまでの4ステップ（ローカル整理→GitHub→自動化→セキュリティ）を、実際の環境（2026年7月時点）でそのまま見せます。左がPCの中、右がGitHub上のバックアップ先という対応です。

全体マップ

図3｜全体対応図 — 「何がどこにあり、どこに写しがあるか」

※ memory / skills の「2hごと自動」は、C:\dev の auto-backup-secondbrain.ps1 をOSのタスクスケジューラが定期実行して実現（第7章）。失敗した時だけデスクトップに警告が出る。

「保存済み / 未保存」を一目で（コーポレート＝.claude直下）

.claude直下そのものは.gitではありません。バックアップされているのは中の skills\ と memory\ が"それぞれ別リポジトリ"だから。＝入れ子構造です。

図3.5｜.claude直下の保存状況 — 未保存なのは実質 settings.json だけ。その"核（deny規則）"は控えで確保済み。

なぜこの形なのか（理由の対応表）

記憶フォルダの実物

図4｜索引の実物 — User／Reference／Feedback／Projectの4分類

メモ1枚の実物（ラベル部＋本文の2階建て）

図5｜メモの実物 — 「何があったか＋Why＋How to apply」の型

上級

第二の脳を“さらに強くする”上級オプション（栞・グラフ・AI記憶＋健康診断・取り込み）

大前提：ここまでの土台（GitHub＋Markdown＋索引）で、第二の脳はもう十分です。以下は「必要になったら足す」もの——ツールが多い＝優れている、ではありません。それぞれ複雑さ・維持コスト・事故リスクを足すので、流行に流されて積み上げないのがプロの運用です。

① 栞テク — 大物資料に“目印のMarkdown1枚”を添える

PDF・パワポ・エクセルはAIが中身を読みにくく、検索にも引っかからない＝せっかくの資料が“脳の外”に取り残されます。そこで資料1つにつき、「要約＋タグ＋元ファイルへのリンク」だけのMarkdownを1枚添える。得られるのは3つ——AIが要約だけ読めば把握できる（重いPDFを毎回読ませない＝トークン節約）／検索に引っかかる／タグ・リンクでつながりに載る。

② 健康診断（lint）— たまに頼み方1文、ツールは不要

メモが溜まるほど、壊れたリンク・どこからも参照されない孤立メモ・古くなった記述が静かに増えます。これをAIに定期的に探させる——「memoryフォルダの健康診断をして。壊れたリンク／孤立メモ／古くなっていそうな記述／言及だけあって本体がないトピックを一覧にして」と頼むだけです。出てきた候補を直す・消す・統合するのは人（自動修正はさせない＝古い記憶で上書きされる“自己汚染”を防ぐ）。

③ 取り込み（ingest）— 読んだ記事を“知識の型”にして溜める

記事・論文・資料を読んだらAIに渡して「知識リポの型（1テーマ1ファイル・読めば完結・タグ＋関連リンク）に整理して」と頼み、中身を自分で確認してからリポに入れる。読んだものが流れずに資産になります。自動ファイリングはしないのがコツ——海外で話題の“1記事から自動で何ページも生成”系は、ノイズが複利で増えるのと裏表です。候補作りはAI・入れる判断は人——この一手間が品質の担保。大物（PDF等）は①栞テクと併用します。

なぜ「門番」と「掃除」が要るのか — 入れすぎのリスク

やみくもに入れることのリスクは、感覚論ではなく研究で確認されています。ただのメモアプリなら、入れすぎても「読まないメモが増える」だけ。でもAIに読ませる前提の第二の脳では、溜めたメモをAIが読んで答えを作るので、古い情報・未検証のメモ・他人の受け売りが、いつの間にか「自分の知識」として答えに混ざり始めます。入れた量は資産に見えて、“AIの答えを濁らせる負債”にもなる。

研究の裏付け：2026年2月公開の研究「Long Context, Less Focus」は、最新モデル群を1K〜256Kトークン・37万問超で検証し、「文脈が長くなるほど、パーソナライズの質が一貫して劣化する」と報告（原因は“注意の希釈”）。Claudeの開発元Anthropicも「コンテキストは有限資源。増やすほど想起精度は下がる」と公式に明言しており、Claude Codeの記憶機能自体が“索引から必要な分だけ読む”設計になっています。

④グラフと⑤AI記憶 — 焦らなくていい2つ

④グラフ：メモ同士を[[リンク]]でつなぐと相関図になり、忘れていたつながり・迷子メモ・知識の手薄な領域が“見える”ようになります。ただし線は自分で手でリンクを書いて初めて増えるので、メモが数十〜数百枚の今はフォルダ＋索引で十分。Obsidianは保存場所ではなく“閲覧アプリ”（同じMarkdownを開くだけ）なので、いつでも後付けできてロックインもありません。

⑤AI記憶（MCPの記憶ツール）：索引すら指定せずAIが関連する過去を自動で引っ張る仕組み。ただし効いてくるのは数千枚規模からで、古い・間違った記憶を勝手に持ち出す“自己汚染”の事故リスクもあるため後回しが正解。今の「索引（MEMORY.md）を毎回自動で読み、関連メモをAIが自分で開く」方式は、軽量な“想起”としてすでに成立しています。

付録

用語ミニ辞典

拡張子（.md .docx など）

ファイル名の末尾につく「種類ラベル」。.mdはただの文章ファイル。

Markdown

「#を付けたら見出し」等のかんたんな記号ルールで書く文章形式。どのアプリ・どのAIでも読める。

リポジトリ

GitHub上の「プロジェクト1個分の保管箱」。履歴ごと保管される。Private＝自分だけが見られる。

プッシュ

PC側の変更をGitHub（倉庫）へ送ること。これがバックアップの実行にあたる。

索引（MEMORY.md）

メモの目次ファイル。1メモ=1行。毎チャット開始時にAIが自動で読む。

トークン

AIの読み書き量の単位。読む文章が長いほど消費する＝燃費の正体。

RAG

文書を細切れにして「意味が近い断片」だけAIに渡す検索方式。NotebookLMがこの系統。

ロックイン

データがサービス専用の形になり、離れられなくなること。正本を置く場所では避ける。

正本（マスター）

いちばん信頼できる大元のデータ。ここではMarkdown＋GitHubに置く方針。