GitHub と LLM エージェントを用いた個人ワークスペース

·4 分で読めます
LLMClaudeGeminiCodexMarkdownナレッジ管理仕事術
GitHub と LLM エージェントを用いた個人ワークスペース

日々、複数社・複数プロジェクトを同時に関わっており、並行して検討・作業を行うことがあります。

それらの管理を、個人の GitHub プライベートリポジトリに集約し、エージェントに管理してもらうことで、全プロジェクト横断のワークスペースとして活用しています。

リポジトリには以下のような情報が含まれます。

  • 議事録
    • Google Gemini や Circleback による文字起こし
    • 会議のあとに毎回取り込む (カレンダーの終了時刻を見て取り込みをリマインド・後述)
  • 設計書
    • 案件ごとの設計ドキュメント (議事録で決まったことを反映・後述)
  • タスク一覧
    • 全社横断の todo.yaml ひとつに集約 (手では編集せず、朝夕にエージェントが整理・後述)
  • 作業ログ
    • エージェントのセッションから、その日やったことを要約して残す
  • 考えたこと
    • 迷いも結論も thinking/log/ に時系列で追記 (上書きせず・後述)
  • プライベートの行動
    • 釣りやキャンプ、模型製作といった仕事以外の予定・記録も、同列に置く

これらの情報を、プロジェクトを横断して管理することで、過去の設計や判断を再利用でき、あるプロジェクトで得た知見を別のプロジェクトのブラッシュアップに回し、そこで改善したものを元のプロジェクトに戻せます。

成果物の例として、次のようなものがあります。

  • 新規プロジェクトの連続立ち上げでの、アーキテクチャの横展開
    • 前の案件の設計をそのまま引いて、ゼロから考え直さずに立ち上げられる
  • プロジェクトの関連組織からの質疑表
    • 議事録とやりとりが 1 か所に残っているので、誰に何を聞かれ何と答えたかを表に起こせる
  • 予算の策定
    • 過去の見積もりや決定の経緯を横断で引いて、根拠つきで組める
  • 失念しがちなタスクを毎朝思い出す
    • 朝のブリーフが、todo.yaml と各社の文脈から、今日やるべきものを出してくれる
  • メール・Slack メッセージ・ブログ記事などのドラフト文章作成
    • 過去のやりとりや文脈を踏まえて、下書きをまとめて起こせる

なぜ作ったか

きっかけは、同僚が会社の GitHub organization に、その会社の仕事だけをまとめたワークスペースを作っているのを見たことです。

会社のスコープに閉じた使い方でしたが、これを自分流に、複数の会社をまたいで使えないかと思いました。

自分はそれまで、個人用のタスク管理ツールを使っていませんでした。

Markdown で TODO を書く、Apple のメモ帳アプリにリストを作る、案件ごとのタスク管理ツールに個人タスクを足す、といった具合に、プロジェクトによってやり方がバラバラで、どの会社のどの案件で何を決めたかを横断できずにいました。

そこで、ひとつのリポジトリに、会社もプロジェクトもプライベートもまとめて集約することにしました。

集約しても回せるようになったのは、LLM エージェント技術の進歩のおかげです。

大量の Markdown と YAML を読み込んで、優先順位や期日をもとに、いま向き合うべきものを適切なタイミングで差し出してくれるので、ファイルが増えても自分で全部を追いかけずに済みます。

中身はテキストデータだけ

リポジトリの中身は、ほとんど Markdown と YAML だけです。

  • 個人ひとりが扱う量なら、検索は grep で足りる
  • git で差分が追えるので、いつ何を変えたかが残る
  • 端末を変えても git clone で同じ状態になる
  • LLM に読ませる前提でも、結局プレーンテキストが一番扱いやすい

ディレクトリは以下のような構成にしています (社名は伏せています)。

mission.md            # 自分のミッション
todo.yaml             # 全社横断のタスク = 唯一の真実
thinking/
  decisions/          # なぜそう決めたか
  log/                # 日々の思考 (時系列・追記のみ)
companies/{会社}/
  meetings/           # 議事録 (生の文字起こし・メモ)
  meetings_structured/ # 議事録の構造化サマリ
  projects/{案件}/    # 案件ごとの設計ドキュメント
  context.md          # その会社の状況
docs/                 # 判断ルール・運用手順
memory/               # 1 ファイル 1 事実のメモ

関わり方はプロジェクトごとに違いますが、それでも技術は地続きなので、ひとつのリポジトリにまとめています。

会社ごとの文脈やタスクが混ざらないよう、companies/{会社}/ のフォルダと、todo.yaml の各タスクに付ける company で仕切ります。

特定のエージェントに固定しない

エージェントへの共通の指示は AGENTS.md の一枚にまとめ、Claude Code・Codex・Antigravity (Google) は、それぞれのアダプタからこの一枚を読みます。

どのエージェントも同じものを読むので、ツールを乗り換えても、ワークスペースはそのまま動きます。

特定のサービスやモデルにロックインされて一番困るのは、使っている LLM に障害が出たときに、そのあいだ仕事ごと止まってしまうことです。

いつでも別のエージェントに移れるようにしておけば、片方が落ちても、もう片方に切り替えて続けられます。

値上げや仕様変更に振り回されずに済むのも、同じ理由からです。

タスクを todo.yaml で管理する

タスクは todo.yaml ひとつだけを「唯一の真実」にしています。

1 件はこんな形です。

nodes:
  review-matching-spec:
    title: "新方式の仕様レビューに返信する"
    status: in_progress
    company: corp-a
    due: 2026-06-18
    context: "事業部の定例が 6/18 朝なので前日までに"
    src: "Slack #dev 2026-06-15"

各キーは、こう読みます。

  • company … どの会社のタスクか。ここでは corp-a
  • status … 進行状態。in_progress は着手中
  • due … 期日
  • context … なぜ今やるか。判断の前提を一行で書く
  • src … どこから来たか。ここでは Slack のやりとり

決めているのは、この YAML を自分の手で直接いじらないことです。

手で編集を始めると二重管理になって、すぐ破綻します。

代わりに、朝と夕方にエージェントへ整理させ、朝はその日の段取りを相談し、夕方は git のログや議事録から「終わったこと」を判定して畳みます。

朝に予定を読み、会議の終わりを拾う

朝、その日の予定をエージェントに取得させます。

/morning-brief というスキルが Google カレンダーを読み、今日の会議とその終了時刻を、ローカルの一時ファイルに書き出します。

それ以降、メッセージを送るたびに、LLM を使わないフック (シェルスクリプトと jq) が「終わったばかりの会議があるか」を確認し、該当があれば一行だけ「その会議、終わりましたか」と促し、無ければ何も出しません。

そのため、ふだんは存在を感じませんが、会議の直後だけ声がかかります。

会話はこんな感じです。

(会議の終了時刻を過ぎてメッセージを送ると、フックが一行注入)

エージェント: corp-a 定例は終わりましたか。終わっていれば議事録を取り込みます。

> 終わった

エージェント: Circleback から取得しました。文字起こし・メモ・構造化サマリの 3 種類で保存し、取り込み済みとして記録します。

朝に読み込んだ会議が対象のため飛び込みの打ち合わせは拾えませんが、会議のあと「議事録取り込んで」と指示する手間が省け、取りこぼしなく、内容が頭の中でフレッシュな間に要点を抽出できます。

議事録を取り込む

打ち合わせの議事録は、Circleback と Gemini の文字起こしから引っ張ってきて、3 種類に分けて保存します。

1 つめは、生の文字起こしです。

手を入れず、話者ラベルとタイムスタンプ、それと聞き間違いの対応表を付けたまま残します。

# corp-a 定例 — transcript (2026-06-15)
> source: Circleback (meetingId: 200xxxx)。話者 P1=自分 / P2=先方。
> 誤読: 「かきん/可琴」= 課金、「〇〇さん」= 先方 PM (要照合)。冗長部は要約。

## 課金の方針
- [06:03] P1: 月額と従量どちらに寄せるか。先方は従量希望
- [07:10] P1: 従量だとサポートコストが読めない。上限付きの固定で出したい

2 つめは、読みやすく整えたメモです。

# corp-a 定例 — Notes (2026-06-15)
#### 概要
* 課金は「月額固定 + 上限付き従量」で合意
* 次回までに料金表の叩き台を用意する

3 つめは、決定事項・やること・誰が何を持つかを抜き出した構造化サマリです。

# corp-a 定例 — 構造化サマリ (2026-06-15)
> 元議事録: meetings/2026-06-15-corp-a-notes.md / -transcript.md
> 参加 (実発話者): 自分 / 先方 PM

## 決定事項
- 課金は「月額固定 + 上限付き従量」にする (従量だけだとサポートコストが読めないため)

## 次のステップ (assignee 別)
### [自分]
1. 料金表の叩き台を作る (Circleback actionItem 200xxxx)。発言「上限付きの固定で出したい」→ 次回定例まで
### [先方 PM]
1. 社内で上限値の希望レンジを確認

## TODO 候補 (→ 確認後 todo.yaml 反映)
1. `corp-a-pricing-draft` (仮): 料金表の叩き台。assignee=自分。次回定例まで

## 注意フラグ (team.md 照合)
- 「サトウさん」 (先方発言): team.md 未登録。先方の決裁者か要確認 (本サマリでは追跡しない)

3 種類に分けるのには、それぞれ役割があります。

  • 生の文字起こしをそのまま残すのは、あとで固有名詞の聞き間違い (この例なら「かきん」= 課金) や、発言の前後関係を確認したくなるから
  • 構造化サマリは、決定事項を 1 行に落とし、次のステップを担当ごとに分け、自分の担当には元の発言と Circleback の actionItem ID を紐づける
  • todo.yaml に入れる候補は「TODO 候補」として分け、確認してから反映する
  • team.md に無い名前 (この例では「サトウさん」) は、追跡せず注意フラグだけ立てる

話者の取り違えの修正や要約は、生のほうではなく、この構造化の側でやります。

設計を書き、議事録を反映する

案件ごとに、設計ドキュメントを書いています。

議事録から拾った決定事項は、該当する案件の設計に反映し、該当する案件が無ければ確認した上で新しい案件のフォルダを追加します。

実際には、議事録を取り込んだあと、エージェントがこんなふうに更新案を出してきます。

> 6/15 の corp-a 定例を反映して

構造化サマリを読みました。既存の「課金設計」プロジェクトに反映します。

- companies/corp-a/projects/billing/design.md … 料金モデルを「月額固定 + 上限付き従量」に更新 (6/15 定例で合意)
- todo.yaml … 「料金表の叩き台を作る」を追加 (company: corp-a / 次回定例まで / src: corp-a 定例 2026-06-15)

この 2 点で反映してよいですか。該当するプロジェクトが無ければ、新規フォルダの作成を確認します。

この例では、設計ファイルの料金モデルを書き換える点と、todo.yaml にタスクを 1 件足す点の 2 つだけを挙げて確認を求めています。

提案を確認してから反映するので、勝手に設計やタスクが書き換わることはありません。

打ち合わせで決まったことが、宙に浮いたまま忘れられないようにするための流れです。

設計が固まったら、申し送りプロンプトで実装に渡す

設計が固まったら、各リポジトリに渡す「申し送りプロンプト」を書きます。

骨子はこんな形です。

# 申し送り: corp-a 課金 API の実装
## 前提
- 設計: companies/corp-a/projects/billing/design.md (料金モデル = 月額固定 + 上限付き従量)
- API スキーマ (契約) は確定済み: schema.graphql を参照

## このリポジトリでやること
- 月額固定 + 上限付き従量の課金ロジックを実装する
- 上限到達時の挙動は design.md の「上限ポリシー」に従う

## まずレビューから
いきなり実装に入らず、設計の穴と、このリポジトリの既存実装とのズレを先に指摘してほしい。
指摘は設計側に戻すので、対話形式で出すこと。

ポイントは、いきなり実装に入らないことです。

まず作業担当のエージェントに査読・レビューさせ、出てきた指摘を設計担当のエージェントに戻し、双方が納得するまで往復させます。

ここで設計の穴や、リポジトリ側の事情とのズレを潰してから、実装に入ります。

実装は、バックエンド、データ加工、クライアント、管理画面と、複数のサブシステムに分かれることが多いですが、設計と申し送りが先に固まっているので、これらは並行して進められます。

思考ログは追記だけにする

thinking/log/ には、考えたことを時系列で雑に流し、ルールは一つ、上書きせず追記だけにしています。

## 14:30 [corp-a] 課金まわりの設計
月額と従量のどちらに寄せるか迷い中。先方は従量希望だが、
サポートコストが読めなくなるので、当面は月額固定 + 上限付きで提案する。

この例も、結論 (月額固定 + 上限付き) だけでなく、何を迷っていて、なぜその暫定案にしたかまで、そのまま書いています。

きれいにまとめ直したくなりますが、そうすると「迷っていた過程」が消え、後で役に立つのはそちらなので、生のまま残します。

決めきった話だけ、thinking/decisions/ に「なぜそう決めたか」を別ファイルで残しています。

外出先からも、その場で書き留める

このワークスペースは、Claude Code Mobile からも同じように触れます。

外出先で今日の TODO を聞いたり、見つけた記事をブックマークしたり、思いついたことを thinking/log/ に足したり、どれもスマートフォンから投げます。

先日は、ひとり立ち飲み屋で呑んでいるときに実装のアイデアが浮かび、その場でメモを投げておきました。

家に着く頃には忘れているような思いつきも、同じリポジトリに入れておけば、あとで grep で拾えます。

メモリは 1 ファイル 1 事実

覚えておいてほしいことは、memory/ に 1 ファイル 1 事実で置き、先頭に最小限の YAML を付けます。

---
name: feedback-no-circled-chars
description: 丸囲み数字は使わない (ターミナルで表示が崩れる)
metadata:
  type: feedback
---
箇条書きの番号は (1)(2) か 1. で書く。丸囲み文字は使わない。

この例は「丸囲み数字を使わない」という 1 つのルールだけを書いたファイルで、--- で囲んだ部分に name (識別子)・description (一行要約)・type (種別) を持たせ、本文にルールそのものを書きます。

1 ファイルにまとめて書かないのは、後から「この事実だけ直したい/消したい」ができなくなるからです。

索引の MEMORY.md に 1 行ずつポインタを置いて、毎回読み込みます。

スキルは薄く、判断は docs に置く

朝の段取り、夕方の振り返り、議事録の構造化、といった定型作業は「スキル」に切り出しています。

ここで一度しくじり、「タスクを完了とみなす条件」を朝のスキルと夕方のスキルの両方に書いてしまい、片方だけ直して食い違いました。

それ以来、判断のルールは docs/ に一度だけ書いて、スキルからは参照するだけにしています。

# 完了判定 (done の条件) — docs/task-management.md
- 成果物の存在で判定する (「通知が来た」では未完了)。
  例: 議事録は、ファイルが保存されて初めて done
- commit / push まで終わっているかを git の実状態で裏取りする
- 朝・夕どちらのスキルも、この条件を参照するだけにする

こうしておくと、スキル本体は手順の骨格だけ持ち、判断はこの一か所を直せば両方に反映されます。

コードで重複を避けるのと同じ話で、ドキュメントも重複させると腐ります。

LLM はサブスクリプションの中だけで動かす

気軽に普段使いするため、コストのことを都度考慮しなくてよい、サブスクリプションの範囲でエージェントを利用することを心がけています。

対話のセッションが中心ですが、サブスクリプションの範囲で動く定時・イベント実行 (Claude Code の Routines) も同じ枠の中で使い、ここでも従量課金の API には流しません。

そのぶん、機械的にできる前処理 (ログの抽出や集計) は LLM に投げず、Bash と jq でやり、データを取って整えるのは無料の道具で、判断が要るところだけ LLM に渡します。

捨てたもの

運用してきた過程で、期待した成果が出せず、廃止した仕組みもあります。

各サービスからデータを定期収集する仕組みを、最初に作りました。

Circleback や Slack の Webhook を起点に、新しい議事録やメッセージを自動で取り込んでローカルに溜めておく構想です。

試作を進めるうちに、必要なときに MCP コネクタで取りに行ったり、エージェントのフックで会議の直後だけ促したりすれば足りると分かり、常時動かす仕組みは持たないことにしました。

エージェント自身に、日記を書かせている

このワークスペースに常駐しているエージェントには、その日の振り返りを日記として書かせ、エージェントさん日記 として公開しています。

人間のふりはさせず、エージェントが書いた文章を、こちらで代筆も推敲もせずそのまま載せます。

ただ、著者は業務を見ているエージェントなので、ふつうに「今日あったこと」を書くと機密が漏れます。

そこで書くのは仕事の中身ではなく、社名・人名・案件・数字といった固有名詞を抜いたあとに残る、経験やメタの部分だけにしています。

公開の前には、実在の社名・人名を集めた denylist と数字の検出を下書きに当てる機械チェック (LLM は使いません) を通し、そこを抜けたものをプルリクエストにして、自分がレビューしてマージしたぶんだけが世に出ます。

同じ仕組みを自分用に作るには

同じ仕組みは、お使いのエージェントに、この記事と次のプロンプトを渡すところから始められます。

このブログ記事「GitHub と LLM エージェントを用いた個人ワークスペース」を読み、
同じ仕組みを私用にスキャフォールドしてください。

https://ja.ngs.io/2026/06/26/personal-workspace/index.md

# 作るもの
git リポジトリひとつ。中身は Markdown と YAML だけ。
以下を、空のテンプレートとサンプル 1 件ずつで用意してください。

- mission.md            … 自分のミッション
- todo.yaml             … 全タスクを集約する「唯一の真実」
- thinking/decisions/   … なぜそう決めたか
- thinking/log/         … 日々の思考 (時系列・追記のみ)
- companies/{会社}/     … 会社ごとに context.md / meetings/ / projects/
- docs/                 … 判断ルール・運用手順
- memory/ + MEMORY.md   … 1 ファイル 1 事実のメモと索引
- AGENTS.md             … エージェントへの共通の指示

todo.yaml の 1 タスクは title / status / company / due / context / src を持たせる。

# AGENTS.md に書く運用ルール
- todo.yaml は手で編集しない。朝と夕にエージェントが整理する
- thinking/log/ は上書きせず追記だけにする
- 判断ルールは docs/ に一度だけ書き、スキルからは参照する
- 動かすのはサブスクリプションの範囲だけ。機械的な前処理は Bash や jq で

まず構成案を提示し、私の確認を取ってからファイルを作成してください。

おわりに

使っているのは Markdown と YAML と git、それに Claude など各エージェントのサブスクリプションだけです。

それでも、議事録から設計、実装までが一本の線でつながって、「決めたこと」と「考えたこと」が流れずに残るようになりました。

共有

X Facebook LinkedIn Bluesky