AI Session Notes - 2026-03-08
学んだこと
- AI コーディングツールの
context remaining と hourly/daily/weekly limit は別物として読む。
- CLI に
status 風コマンドがあっても、確認できるのが認証状態だけで、利用枠までは見えないことがある。
- 利用枠を把握するときは、実際のアプリ UI や公式の usage 画面で、どの指標が何を意味するのかを切り分けて確認する。
- 週次利用枠は固定のカレンダー週ではなく、rolling window 的に再計算されることがあるため、突然「残量が復活した」ように見える場合がある。
詳細
context remaining は、その会話で保持できる文脈ウィンドウの残量を示す。5h limit や weekly limit のような表示は、一定期間内の利用枠を示す。- 同じ「残り%」でも意味が異なるため、残量評価では指標名ごとに解釈する必要がある。
- 利用枠の再計算タイミングはツール内部実装に依存するため、アカウント単位の変化理由を断定できない場合でも、まずはリセット時刻と window の挙動を疑うのが実務的。
Reasoning Level の使い分け
学んだこと
reasoning は、モデルがどれだけ深く考えてから応答するかの強さを表す。xhigh は複雑な設計判断や厳密レビュー向きだが、通常の相談には重すぎる場合がある。- 日常的な仕様検討や issue 分解では、上位モデルに
high を組み合わせ、難所だけ xhigh に上げる運用がバランスがよい。
詳細
low は軽く速いが、複雑な検討には向かない。high は日常的な設計相談や優先順位整理に向く。xhigh はアーキテクチャ判断や厳密レビューなど、見落としコストが高い場面だけに絞ると利用枠を節約しやすい。
Fast Mode と Reasoning は別軸
学んだこと
- AI コーディングツールの
fast モードと reasoning 設定は、同じものではない。
fast は主にレイテンシや処理速度寄りのモードで、reasoning は思考の深さを制御する。- 実務では
fast + high reasoning のように、速度と精度を別々に組み合わせて運用できることがある。
詳細
- UI 上では、モデル名の横のバッジや slash command が
fast モードを示し、別のドロップダウンやラベルが reasoning 強度を表していることがある。
- そのため、コストや品質の調整では「モデル名」だけでなく「fast 設定」と「reasoning 設定」を分けて読む必要がある。
- 軽い仕様相談や文面整理では
fast を有効にし、重い設計判断では fast を外す、という運用がしやすい。
Obsidian Vault Settings の扱い
学んだこと
- Obsidian は vault ごとの設定を
.obsidian/ に保存する。
.obsidian/ には閲覧レイアウトやプラグイン設定などのローカル設定が入り、Markdown 本文とは別物として扱う。- 個人用の閲覧設定であれば、通常は Git 管理せず
.gitignore に追加するのが自然。
詳細
- 共有したいのがノート本文だけなら
.obsidian/ を追跡しない方が差分ノイズを減らせる。
- チームで見た目やプラグイン構成まで固定したい場合だけ、限定的に管理対象にする価値がある。
セッションのクリアと分岐の考え方
学んだこと
- AI コーディングツールに
clear context 専用コマンドがない場合、実質的なリセット手段は「新しい会話を始める」ことになる。
resume は文脈を引き継いで続きから作業する操作で、fork は既存セッションを分岐させる操作として理解すると混乱しにくい。- 「今の文脈を捨てたい」のか、「続きをしたい」のか、「分岐したい」のかを分けて考えると、適切な操作を選びやすい。
詳細
clear と new session は目的が近いが、ツールによっては前者がなく後者だけが提供される。- その場合、履歴を消すのではなく「新しいセッションに切り替える」運用が現実的なコンテキスト管理になる。
- 文脈汚染を避けたい作業では、新しい会話を切ること自体が重要な運用テクニックになる。
Claude Code への画像連携方法
学んだこと
- Claude Code は画像入力に対応しているが、macOS のクリップボード経由の
Cmd+V ペーストはうまく動作しないことがある。
- 確実な方法は、スクリーンショットをファイルとして保存し、そのパスを伝えること。
- ターミナルへのファイルのドラッグ&ドロップでもパスが入力される。
詳細
- macOS のスクリーンショット撮影方法:
Cmd+Shift+3 / Cmd+Shift+4 — ファイルに保存（デフォルトはデスクトップ）Cmd+Ctrl+Shift+3 / Cmd+Ctrl+Shift+4 — クリップボードにコピー- Claude Code ではクリップボードからの画像ペーストが期待通り動作しない場合があるため、ファイルパス指定が最も安定した方法。
静的 SPA の配信とフォールバック
学んだこと
- 静的ホスティングでも、ビルド後に HTML/CSS/JS を配る SPA は十分公開できる。
- ただし History API を使う SPA は、深い URL を直接開いたとき
index.html に戻すフォールバック設定が必要になる。
- 静的サイトの配信先を選ぶときは、料金だけでなく SPA fallback の設定しやすさも比較軸に入れると判断しやすい。
詳細
hash routing なら不要なこともあるが、pushState ベースの SPA では catch-all rewrite がないと直アクセスで 404 になりやすい。- Cloudflare Pages では
_redirects に /* /index.html 200 を置く方法がある。
- 任意リライトが弱い配信先は、単純な静的配信には向いても History API ベースの SPA には一段不向きになりやすい。
Cloudflare Pages の build/deploy モデル
学んだこと
- Cloudflare Pages には
Git 連携で Cloudflare 側が build/deploy、ローカル build 後に direct upload、CI から deploy という複数の運用パターンがある。
- GitHub リポジトリの公開/非公開と Cloudflare Pages への接続可否は別で、private repository でも運用できる。
- Free plan の build 上限は build 時間ではなく build 回数として数えられるため、運用感覚は「push の回数」に近い。
- 独自ドメインをまだ取得していなくても
*.pages.dev で先に公開を始められる。
詳細
- Git 連携では push をトリガーに Cloudflare が build するため、ローカルで何度 build しても Pages の build 回数は増えない。
- build 回数に上限があるサービスでは、ローカルで検証を済ませてからまとまった単位で push する方が無駄なデプロイを減らしやすい。
- project 名、公開 URL、Git repository 名は別概念として扱えるので、ブランド名の検討とコード管理を切り分けやすい。
.gitignore と tracked file の切り分け
学んだこと
.gitignore は新規の untracked file を無視する設定で、すでに Git 管理されているファイルは自動では外れない。- あるパスが追跡中かどうかを確認するには
git ls-files <path> が手早い。
- ローカルにファイルを残したまま Git 管理だけ外したいときは
git rm --cached <path> を使う。
- エディタや AI ツールの個人設定、実験用の scratch file は最初から ignore に寄せると公開前の棚卸しが楽になる。
詳細
git rm --cached は index だけを更新するので、working tree 上のファイル本体は削除しない。- 「ignore したのに remote に残っている」というケースは、すでに tracked なファイルで起きやすい。
- 公開前の確認では
.env や秘密鍵だけでなく、ローカルツール設定や一時ファイルも見直し対象にすると抜け漏れを減らせる。
差分仕様が積み上がるときのドキュメント整理
学んだこと
- バージョンごとの差分仕様を積み上げる運用は、読むための知識ベースではなく、書くための儀式になりやすい。
- 現在の挙動を素早く把握したい文書は、差分の連鎖ではなく「現在の正」を1枚に集約した方が機能しやすい。
- 長寿命の文書は
current spec と decision log に絞り、タスク分解、進捗、AI向け依頼文のような短寿命情報は Issue や PR に寄せると保守しやすい。
- 参照されない旧文書はアーカイブとして残すより削除した方がノイズ削減に効くことがあり、必要な履歴は VCS と Issue/PR から辿ればよい。
詳細
- 文書の価値は「作ったか」ではなく「後から参照されるか」で決まる。
- 現在仕様を知るために複数版の差分適用が必要な構造は、読むコストが高すぎて実運用では機能しにくい。
- 実務では、ドキュメントを寿命で分けると整理しやすい。
- 長寿命: 現在仕様、意思決定ログ、実装地図
- 短寿命: タスク分解、進捗、実装依頼文
- 短寿命情報をリポジトリ常設文書として抱え込むより、Issue、PR、Git history に委ねた方が運用負荷を下げやすい。
参考リンク
メタ情報
- ツール: Codex, Claude Code
- 関連技術: AI coding tools, rate limits, reasoning configuration, fast mode, session management, Obsidian, macOS, static hosting, SPA routing, Cloudflare Pages, GitHub Actions, Git, gitignore, documentation strategy, ADR, issue-driven workflow