記事一覧

⚠️ 免責事項: 本記事は技術解説であり、金融商品取引法上の投資助言には該当しません。シミュレーション結果は将来の利益を保証するものではなく、先物取引には元本超過損のリスクがあります。実運用はご自身の責任で行ってください。 BTC 自動売買 × モンテカルロ法の記事で紹介した「1万通りのシナリオを回してから売買判断する」アーキテクチャを、日本株インデックス — 具体的には 日経225 マイクロ先物 に応用してみます。 BTC と違って日経225 はザラ場の時間が決まっています。しかしナイトセッションがあり流動性は世界最高水準、さらに分散効果で個別株のジャンプリスクが平滑化されるため、幾何ブラウン運動（GBM）を前提とするモンテカルロと相性が良いという利点があります。 TL;DR 勝率 55% かつ期待値 50pt 以上のときだけ発注する二段ゲート ケリー基準で枚数を自動調整（上限 25%） 1万パスの Monte Carlo を翌営業日終値分布として生成 日経225 マイクロ先物がモンテカルロ法と相性が良い 3 つの理由 個別株を Monte Carlo で扱おうとすると、決算・TOB・不祥事・配当落ち といった「ジャンプイベント」が頻発し、log-normal を前提とする GBM の精度が出にくくなります。日経225 は約 225 銘柄の加重平均なので、これらの個別イベントが分散効果で平滑化されます。 主な利点は次の通りです。 GBM の前提との整合性: 個別株より裾が薄く、log-normal 近似が機能する 流動性: 大証ラージ・ミニ・マイクロいずれも世界トップクラスの板厚 取引時間: 日中 8:45〜15:45、ナイト 17:00〜翌6:00（2024年11月5日以降の現行仕様）で、米国市場と連動した値動きをほぼ即時に反映できる マクロ情報主体: FOMC・日銀会合・CPI・地政学など、Claude が要約しやすい情報源で判断できる 日経225 マイクロ先物の仕様 マイクロ先物は 2023年5月29日に大阪取引所で取引が開始された商品で、ミニ先物のさらに 1/10 サイズです。 項目 内容 取引単位 日経平均株価 × 10 円 呼値 5 円 必要証拠金（目安） 1〜2万円台/枚（SPAN により変動） 取引時間 日中 8:45-15:45 / ナイト 17:00-翌6:00 ※2024年11月5日以降 限月 期近〜期先複数 たとえば日経225 が 38,000 円のとき、1 枚あたりの想定元本は 380,000 円ですが、レバレッジで実際の証拠金は 20,000 円前後。1 ティック（5円）動くと 50円の損益なので、検証コストが非常に低く、自動売買のプロトタイピングに向いています。 ...

Obsidian Vault を Claude Code に繋ぐ実践編 では、読み取り側（Vault → プロジェクト）の設定パターンを整理しました。本記事はその続編で、書き戻し（writeback）側（プロジェクト → Vault）の設計を扱います。 ここを設計しないと、Vault は「過去の自分が書いたノート集」のまま古びていきます。プロジェクトで詰まったこと・学んだこと・設計判断の根拠が Vault に還流して初めて、AI Agent が「3 ヶ月前のあの話、応用できないか？」を提案できるようになります。 書き戻し設計で外せない3つの原則 具体的なパターンに入る前に、絶対に外せないルールを確認します。 AI に Vault の正本（topics/ や projects/ の本文）を直接書かせない Obsidian の [[リンク]] 構造とノート間の整合は、人間が編集してきた歴史の積み重ねです。AI に直接書かせると、リンク切れ・重複ノート・タグ揺れが一気に発生します。 inbox/ を必ず噛ませる AI は ~/Documents/ObsidianVault/inbox/ にしか書かない。inbox/ は「下書き置き場」と割り切り、人間が後で内容を吟味して Vault 本体に統合します。 書き戻す対象は「リポジトリに収まらない知見」だけ コードや設計書はリポジトリの docs/ に書きます。Vault に書くのは、プロジェクトを跨いで再利用される可能性のあるメタ知識 だけです。 つまり「AI が inbox/ に下書きを溜める → 人間が週次レビューで Vault 本体に統合する」という二段階フローを基本形にします。AI は下書き工場、人間は編集長、という分業です。 permissions と MCP の分離設計 書き戻しを安全に行う最大のコツは、読み取り用 MCP と書き込み用 MCP を別サーバとして分離する ことです。前作で触れた permissions 設計 を一段深めます。 1 2 3 4 5 6 7 # 読み取り専用ルート: Vault 全体を grep / Read できるが書き込みは禁止したい claude mcp add -s local vault-readonly -- \ npx -y @modelcontextprotocol/server-filesystem ~/Documents/ObsidianVault # 書き込み用: inbox/ 限定で AI が書ける claude mcp add -s local vault-inbox -- \ npx -y @modelcontextprotocol/server-filesystem ~/Documents/ObsidianVault/inbox これに加えて、<proj>/.claude/settings.json 側で symlink 越しの書き込みを禁止しておきます（前作で作った <proj>/.claude/knowledge/ — Vault のサブセットを symlink した読み取り専用ディレクトリ — を経由する書き込みを塞ぐ目的）。 ...

Obsidian Vault 書き戻しの自動化 では、3 方式（Claude Code hooks / Git クライアントフック / GitHub Actions）の使い分けをまとめました。そこで「GitHub Actions は会話文脈が失われる・Vault に書けない」と書きましたが、これは cloud-hosted runner を前提にした話です。self-hosted runner（GitHub の job を手元のマシンで実行する仕組み）に切り替えると、その制約が一気に外れます。 本記事では、自宅 Mac を self-hosted runner にして、PR マージのイベント駆動で claude -p を ローカル文脈（Vault・Skills・CLAUDE.md・MCP サーバ）の中で動かし、Vault に直接書き戻す構成を解説します。ここでの「ローカル文脈」は 対話履歴ではなく、ファイルシステムに永続化された個人資産のセット を指す点に注意してください。シリーズ 5 部作の最終ピースです（思想編 → 読み取り側 → 書き戻し設計 → フック自動化 → self-hosted runner）。 なぜ self-hosted runner が正解になるか cloud-hosted Actions の最大の弱点は次の 3 点でした。 Vault が手元のファイルシステムにあるので、cloud runner からは見えない ローカルの MCP サーバ（vault-readonly / vault-inbox）に接続できない ローカルの Skills や CLAUDE.md が読めず、/summary-back-to-vault を呼べない self-hosted runner は「ジョブは GitHub のイベント駆動で立ち上がるが、実体は手元のマシンが処理する」というハイブリッドです。3 つの弱点がすべて解消します。 ...

開発者にとって、GitHubは事実上の「最強のナレッジベース」になりつつあります。Issue・PR・Wiki・Markdown ドキュメント — 仕事に必要な情報のほとんどがリポジトリの中で完結しており、コードの近くにドキュメントを置く「Docs as Code」のスタイルは、エンジニアリングとして極めて洗練されています。 それでも 2026 年に入ってから、「AI Agent + Obsidian」の組み合わせが開発者コミュニティでホットになり続けています。GitHub で完結しているなら無理に Obsidian を入れる必要はないはずなのに、なぜこれほど話題になるのか。本記事ではその違いを、特に AI Agent に渡せる「文脈の質」 という観点から整理します。 結論を先に書くと、すべてが構造化された「プロジェクト」単位で完結していて、現状の運用にストレスがないのであれば、無理に Obsidian を導入する必要はありません。ただし、「プロジェクトを跨いだ伏線回収」を AI にやらせたい瞬間が来ると、思想の違いが効いてきます。 GitHub方式とObsidian方式の決定的な違い 最大の違いは、情報の「繋がり方」の思想です。 比較軸 GitHub方式（プロジェクト管理型） Obsidian方式（ネットワーク型） 情報の構造 ディレクトリ構造（階層型・縦割り） グラフ構造（網の目型・横断的） 主な単位 リポジトリ / Issue / PR / Wiki ノート（アイディア、ファクト、ログなど） AIとの相性 コンテキストがプロジェクト内に閉じる プロジェクト間を跨いだ「点と点の結合」が得意 向いている情報 目的・ゴール・成果物が明確なもの 抽象的なアイディア、長期的な知見、個人の備忘録 検索の単位 リポジトリ単位の全文検索 Vault 全体のリンク・タグ・全文検索 GitHub は「プロジェクトという箱」に閉じることで一貫性と版管理を担保します。Obsidian は「ノート」というアトミックな単位を Vault 全体にフラットに置き、[[リンク]] で網の目を作ることで横断性を担保します。どちらが優れているという話ではなく、扱う情報の性質によって適切な箱が違うだけです。 「プロジェクトの壁」を越える横断性 GitHub はリポジトリごとに境界線がはっきり分かれています。これは「コードと文脈をセットで版管理する」目的にはとても合っていますが、知識の再利用にはコストがかかります。 GitHub の場合: プロジェクト A で得た「Next.js の認証に関する知見」は、リポジトリ A の docs/ か Wiki か Issue 内コメントに残ります。プロジェクト B を始めたときにそれを再利用するには、「どこに書いたか」を思い出して検索しに行く必要があります。複数リポジトリを横串で検索したい場合は gh search code などに頼ることになります。 Obsidian の場合: 「Next.js の認証」という独立したノートを作っておき、プロジェクト A からも B からもリンクを貼ります。情報がプロジェクトに属するのではなく、知見そのものが独立して進化していく点が決定的に違います。 つまり、GitHub は「プロジェクトに紐づく情報」を蓄積するのに最適で、Obsidian は「プロジェクトから独立した知見」を蓄積するのに最適だ、と整理できます。 ...

GitHubで全部完結する開発者にObsidianは本当に必要か？ では、Obsidian を併用する場合の「思想差」と「AI Agent に渡せる文脈の質」を整理しました。本記事はその実践編です。特定のプロジェクトで Claude Code セッションを行うときに、個人の Obsidian Vault を併用してエージェントに処理させるには、CLAUDE.md / Skills / Settings をどう階層管理すべきか を具体的な設定例で示します。 ポイントは次の3つです。 Claude Code の設定階層（global / project / local）を理解して役割分担する Vault は gitignored 層 で繋ぐ（リポジトリにパスを残さない） CLAUDE.md には安定パスを書く — Vault の生パスを書かない（symlink 経由で参照） Claude Code の3層構造を整理する まず大前提として、Claude Code の設定は 3 層あり、それぞれ用途が違います。 階層 主なファイル Git 管理 使いどころ Global (user) ~/.claude/CLAUDE.md / ~/.claude/skills/ / ~/.claude/settings.json 個人の dotfiles で管理（任意） 全プロジェクト共通の個人スタイル・横断スキル Project <proj>/CLAUDE.md / <proj>/.claude/skills/ / <proj>/.claude/settings.json / <proj>/.mcp.json リポジトリにコミット プロジェクト固有の規約・公開してよい設定 Local <proj>/.claude/settings.local.json .gitignore で除外 Vault パスなど個人秘匿情報を置く claude mcp add の --scope（-s）オプションも、これと同じ 3 値を取ります（local / user / project）。重要なのはデフォルトの挙動です。 ...

Claude Code から個人 Obsidian Vault に「書き戻す」設計 では、書き戻しの設計パターンとして summary-back-to-vault スキル / Daily Note 追記 / ADR 二重書きの 3 つを示しました。本記事はその続編で、書き戻しを自動化する仕組みを扱います。 スキルを作ったとしても、毎回 /summary-back-to-vault と手で打つのは続きません。トリガを自動化しない限り、書き戻しは「気が向いたときだけ」になり、Vault は古びます。本記事では Claude Code のフック・Git のクライアントフック・GitHub Actions の 3 方式を、それぞれが拾えるトリガと文脈の違い に着目して整理します。 自動化候補の俯瞰 書き戻しを発火させる場所は大きく 3 つあります。 方式 トリガ位置 セッション文脈 適性 Claude Code hooks（PostToolUse, Stop, SessionEnd 他） セッション内、ツール呼び出し前後 ✓ 会話履歴・スキル・MCP がすべて生きている AI Agent と最も相性が良い Git クライアントフック（post-merge, pre-push など） クライアント側、git pull / git push 等 ✗ PR の diff だけ Vault が Git リポジトリ化されている人向け GitHub Actions サーバ側、pull_request: closed 等 ✗ PR メタデータのみ マシンを開いていなくても回したい場合 書き戻しに必要な「会話の文脈（なぜそう判断したか／どこで詰まったか）」を保てるのは Claude Code フックだけです。Git フックや Actions は PR の diff と説明文しか見えないため、サマリの「中身の濃さ」が大きく落ちます。これが本記事の核心です。 ...

あすけんとは あすけん は、日々の食事を記録して栄養バランスをグラフで可視化する無料の食事管理アプリです。 カロリーカウントだけでなく、タンパク質・脂質・炭水化物・ビタミン・ミネラルといった各種栄養素が摂れているかを一覧で確認できる点が特徴です。 公式サイト: https://www.asken.jp/ 過去のダイエット（カロリー制限・糖質制限）で失敗を繰り返した筆者が、あすけんを使って 6ヶ月で7kgの減量に成功 した体験をもとにまとめます。 過去のダイエット失敗歴 カロリー制限 → リバウンド 1日1,100kcal以下に制限するという厳しいカロリー制限を試みたが、ストレスからやけ食いが頻発し、最終的にダイエット開始前よりも体重が増えてしまった。 糖質制限 → 体調不良 1日90g前後の糖質制限は最初の1週間で−1.5kgという成果を見せたが、数週間後に便秘・疲労感・原因不明の不安感が現れ中止した。食事を戻した途端に体重も戻った。 あすけんダイエットの方法 シンプルに言えば、食事を記録して日々改善していくだけ。目標は厳しい制限ではなく「ゆるく続けること」。 1. まず記録を日課にする 毎食後でなくてよい。「毎朝カフェで前日分をまとめて入力」など、自分のリズムに合わせて記録を続ける。食べすぎた日でも記録をやめないことが重要。 2. 週単位で食事内容を見直す 1週間ぶんの記録を見返し、 痩せていた週：何が良かったか 増えた週：何が良くなかったか をノートに書き出す。「疲れた日の惣菜弁当で太った → 週末に作り置きする」といった具体的な改善につなげる。 3. 自分を褒め・労う 生理前など体重が増えやすい時期に「なんで太るの！」と自分を責めると自暴自棄になりやすい。「生理前は+2kgまで許容」「この1週間でこれだけできた」と意識的に自分を労う。 あすけんをおすすめする3つの理由 入力が簡単 手動入力はほとんどの料理・コンビニ惣菜・チェーン店メニューが登録済みで、名前を打ち込むだけで完結する。プレミアム版（有料）では料理の写真を撮ると AI がメニューを自動認識 してくれる機能も使える。 コミュニティでモチベーション維持 ブログ機能 があり、他ユーザーの食事・運動・減量記録を参照できる。身長・体重が似ているユーザーを検索してフォローする機能もあり、孤独になりがちなダイエットを続ける動力になる。 栄養バランスがグラフで一目瞭然 毎食後に摂取した栄養素のバランスがグラフ表示される。不足している栄養素と、それを補うための食材・食べ方のアドバイスも表示されるため、栄養の知識が自然と身につく。 注意点 数字に囚われすぎない 全項目を完璧な適正量にしようとすると負荷が高い。「大きく外れていなければOK」くらいのスタンスで使うほうが長続きする。 無料版でも十分 有料版（月額480円・税込）では画像認識入力・1食ごとのアドバイス・PFCバランス管理が追加される。ただし画像認識は自炊メニューで精度が落ちる場合もあり、手動入力が中心になるなら無料版でも十分な機能が揃っている。 他人のダイエット結果と比べない 同じアプリを使っていても体質・生活習慣・目標は人それぞれ。他のユーザーの劇的な結果に焦らず、自分のペース（月−1kg程度）を維持することが最終的な成功につながる。 まとめ あすけんの強みは、「制限」ではなく「記録と気づき」をダイエットの軸に置いている点にある。カロリー制限や糖質制限のように特定の食品を断つのではなく、自分の食生活のパターンをデータ化し、少しずつ改善していくアプローチは再現性が高い。 厳しいダイエットで挫折した経験がある人こそ、まず1週間だけあすけんで食事を記録してみてほしい。 参考: あすけんアプリでゆるダイエット【結果】6ヶ月で7kgの減量に成功！

はじめに 「AIにコードを書かせるのは得意になったが、完成品が要件とずれていて全部作り直しになった」——そんな経験はないだろうか。 Vibe coding（感覚的なプロンプトだけでAIにコーディングさせるスタイル）は手軽な反面、AIとの認識齟齬が後から発覚してリワークが発生するリスクをはらんでいる。 OpenSpec は、その問題を「仕様駆動開発（SDD: Spec-Driven Development）」で解消するフレームワークだ。2025年8月に登場してから急速に普及し、2026年5月時点で⭐50,000超を獲得している。 GitHub: Fission-AI/OpenSpec npm: @fission-ai/openspec ライセンス: MIT Vibe Codingの落とし穴 AIコーディングアシスタントは非常に強力だが、要件がチャット履歴の中にしか存在しない場合、出力は予測不能になりやすい。よくある失敗パターンは次のとおり。 「ざっくり作って」と頼んだら意図と全く異なる設計になった 途中で要件変更を伝えたら、AIが古い前提を引きずった 長いセッションでコンテキストが失われ、最初の仕様が無視された OpenSpecはこれを「コードを書く前にAIと仕様に合意する」プロセスを導入することで防ぐ。 OpenSpecとは OpenSpecは、AIコーディングアシスタント向けの軽量な仕様レイヤーを提供するフレームワーク。プロジェクトに openspec/ ディレクトリを作り、変更ごとに proposal・specs・design・tasks の4つのアーティファクトを生成・管理する。 設計哲学: 1 2 3 4 5 → fluid not rigid （柔軟、固定フェーズなし） → iterative not waterfall （反復的、ウォーターフォールではない） → easy not complex （シンプル） → built for brownfield （既存プロジェクトにも対応） → scalable from personal projects to enterprises 主要コマンド（/opsx:* スラッシュコマンド） OpenSpecは /opsx:propose から始まる一連のスラッシュコマンドで動作する。 ...

背景: 日本語の「言語税」をどこで払うか 先日の記事で、日本語入出力が英語比 1.48 倍のトークンを消費すること、Claude では最大 1.94 倍にもなることを取り上げた。 しかし現実問題、ブログ記事本文・コミットメッセージ・GitHub PR の説明・許可プロンプトなど、最終アウトプットが日本語であること自体が要求であるケースは避けられない。Claude Code を使い続ける限り、日本語コストはゼロにはならない。 問いを言い換えると、こうなる: 「日本語境界を保ったまま、実トークン消費を構造的に減らせる場所はどこか？」 検討した 5 案 案 仕組み 効く場面 弱点 A. 翻訳プロキシ (Ollama) ユーザー入力 ja→en、Claude 応答 en→ja を中間 LLM が翻訳 「思考・指示が日本語で出来ればよい」用途 ツール結果・ファイル内容・git diff まで翻訳経路に入り破綻 B. 部分英語化 思考・指示は英語、最終成果物は日本語のまま 大半の開発作業 削減率は応答側ほど効かない C. Prompt Caching 徹底 CLAUDE.md・Skills・MCP 出力をキャッシュ 日本語のまま実コストを大幅削減 設計工数が必要 D. Caveman プロンプト 「原始人みたいに喋れ」で日本語応答を圧縮 既存実績手法（最大 80% 削減） 文体が崩れるので公開記事には不向き E. モデル切替 Gemini など日本語効率の良いモデルへ部分委譲 翻訳・要約などコモディティ作業 Claude のハーネス連携を捨てる 翻訳プロキシ案 (A) が筋悪な理由 「ローカル LLM で Claude Code の入出力を翻訳する」というアイデアは一見魅力的だが、Claude Code は対話 AI ではなく エージェント環境 であることを思い出す必要がある。 ...

症状 blog-batch.sh で夜間バッチを回した結果、こんな状態になっていた: 同じ wiki ファイル（content/wiki/concepts/harness-engineering.md、content/wiki/tools/claude-code.md）が複数の blog PR で同時に変更されていた main にマージしようとすると毎回コンフリクト 直近の #368・#369・#371・#372 はすべてこの原因で手動コンフリクト解消が必要だった 調査して原因が判明したので、修正内容と「LLM スキルを書くときに気をつけるべきポイント」を共有する。 PR の中身を見ると 3 コミットあった 通常の /blog で作った PR は「記事 1 本分の 1 コミット」のはずだが、見ると 3 コミットあった: 1 2 3 35a61c2 Add blog post: トレーダーのSランクスキル5選... 86e5bd4 Update wiki-last-ingest.txt: mark all posts through 2026-05-07 as ingested 0bc4e1f Update Wiki: ingest posts 2026-04-15 through 2026-04-21 (5 updated, 16 new pages) 2 つ目と 3 つ目は wiki ingest の結果コミット。これが各 blog PR に混入していて、複数 PR で同じ wiki ファイルを並行更新 → コンフリクトという流れ。 ...