AIと並行開発していると情報が散らかる ── Notion / Obsidian / docs / Git を「役割」で分けて整理する

Posted at 2026-06-13

対象読者： AIにコーディングを手伝ってもらっている人 / 個人開発・並行開発で情報が増えすぎて困っている人
読了時間： 約7分

この記事のポイント（3行）

AIと開発すると、コードもメモも記事ネタも ものすごい速さで増える
全部を1か所（Notionだけ・Obsidianだけ・AIだけ）に押し込もうとすると、たいてい破綻する
「置き場所を役割で分ける」 だけで、情報の迷子がかなり減る

はじめに：AIは速い。でも情報も同じ速さで散らかる

AIと一緒に開発していると、情報がものすごい速さで増えていきます。

コードを書く。PRを作る。障害が起きる。関係者に説明する。記事を書く。次のアイデアが浮かぶ──。

PR（プルリクエスト） ＝「この変更をプロジェクト本体に取り込んでください」とお願いする単位。コードの変更をまとめて確認・記録する仕組みです。

気づくと、docs（ドキュメント用フォルダ）、Notion、チャット、Git、ローカルのメモが全部ごちゃごちゃになります。

私自身は、複数の git worktree を使って、いくつかの開発を並行して進めています。

git worktree（ワークツリー） ＝ 1つのGitリポジトリから、複数の作業フォルダを同時に切り出せる仕組み。作業（ブランチ）ごとにフォルダを分けられるので、「ぶつからない並列開発」ができます。

たとえば、こんな単位で並行しています（いずれも自分の開発カテゴリの例です）。

試験対策ツール
授業用プラットフォーム
研究・3D実験場
投資・補助金まわりの資料づくり

この状態でAIに開発を手伝ってもらうと、便利な一方で「どこに何があるか」がすぐ分からなくなります。

そこで私は、情報の 置き場所を役割で分ける ことにしました。

結論：6つの「役割」に分ける

自分の中では、こう分けるのが一番わかりやすかったです。

置き場所	役割（ひとことで言うと）
Notion	いまどうなっているかを見る場所
Obsidian	学び・考え・記事ネタを育てる場所
docs	実際の記録・原本を置く場所
Git	コードと変更履歴を守る場所
AI	読む・要約する・分類する・下書きする係
人間	判断する・公開する・責任を持つ係

大事なのは、次の3つを やらない ことでした。

全部をNotionに入れようとしない
全部をObsidianで管理しようとしない
全部をAIに任せようとしない

それぞれに役割を持たせて、得意なことだけをやらせる。これが効きました。

Notion ＝「現在地」を見る場所

Notionには、開発のナレッジハブのようなデータベース（DB）を1つ作ります。

ここに入れるのは「あとから人間が見て、いまの状況を把握したい情報」です。

開発状況
完了したPR
障害記録
意思決定（なぜそう決めたか）
次のタスク
worktreeごとの状態
関連リンク

DBには、たとえばこんな項目を持たせます。

項目	例
名前	route-optimizer 設計見直し
種別	開発状況 / 障害 / 意思決定
ステータス	未着手 / 進行中 / 完了
日付	2026-06-13
worktree	route-sim
タグ	#設計 #振り返り
要約	AIが書いた1〜2行の要約
関連リンク	PRやdocsへのリンク

Notionが向いているのは「一覧で見たい情報」です。

「これは完了したのか」「どのworktreeの話か」「障害なのか、ただの開発メモなのか」「関連PRはどれか」── こういう 台帳的な管理 に強いです。

Obsidian ＝「考えを育てる」場所

Obsidianには、いまの状態ではなく、学びや考えを置きます。

なぜその設計にしたのか
障害から何を学んだのか
記事にできそうなネタ
医療AI・教育AIについての考え
自分の開発スタイル
将来また使いそうな知識

Notionが「台帳」なら、Obsidianは「自分の頭の中の地図」です。

おすすめは、docsを全部Obsidianに突っ込むのではなく、重要なものだけをリンクすること。最初から完璧に整理しようとすると、まず続きません。

KnowledgeVault/
  10_Projects/        … プロジェクトごとのメモ
    Portfolio.md
    Portfolio.exam.md
    Portfolio.route-sim.md
  20_Areas/           … 継続テーマ
    Security.md
    CI-CD.md
    Route-Optimization.md
  30_Articles/        … 記事ネタ
    Qiita.md
    note.md
  40_Incidents/       … 障害の振り返り
    2026-06-06_Vercel-deploy-incident.md
  50_MOC/             … 地図（目次）
    MOC_開発全体.md
    MOC_授業.md

MOC（Map of Content） ＝「コンテンツの地図」。関連メモへのリンクを1ページにまとめた“目次ページ”のことです。

最初から全部を整理しようとせず、まず MOC_開発全体.md のような 地図を1枚 作るところから始めるのがおすすめです。

docs ＝「原本置き場」

docs は、作業の原本を置く場所です。

作業ログ
設計メモ
報告書
記事ドラフト
障害記録
引き継ぎ資料

ここで大事なのは、docsをきれいにしすぎようとしないことです。

開発中は情報が増えます。多少荒れていても、「原本として残っている」こと自体に価値があります。

ただし、あとから探せるように ファイル名に「日付＋内容」を入れる のだけは徹底します。

2026-06-13_サーバ代が高い_ポーリングをやさしく解説.md
2026-06-07_deploy障害_復旧記録.md
2026-06-08_route-optimizer設計メモ.md

これだけで、検索性がかなり上がります。

Git ＝「履歴」を守る場所

Gitは、コードと変更履歴を守る場所です。ここはAIに勝手に触らせず、変更の記録（履歴）が必ず残る状態を保ちます。

「いつ・何を・なぜ変えたか」が後から追えること自体が、並行開発では大きな安全装置になります。

AIと人間の分担 ── どこまで任せていいか

AIに任せられることは年々増えています。でも、人間にしかできないこともはっきりあります。

私は「どこまでAIに任せるか」を、3段階に分けて考えています。

🟢 完全に自動化してOK（＝「見る・分類する・警告する」まで）

git status の取得
worktreeごとの dirty / ahead / behind の一覧化
新しいdocsファイルの検出
APIキーらしき文字列の検出
ビルドスクリプトに危険な処理が入っていないかのチェック
日次・週次サマリの作成
完了済みPRの一覧化

dirty / ahead / behind ＝ Gitの状態を表す言葉。dirty＝未保存の変更がある、ahead＝ローカルが本体より進んでいる、behind＝本体より遅れている、という意味です。

ポイントは、自動化してよいのは基本的に 「見る・分類する・警告する」まで という線引きです。

🟡 半自動化が便利（＝AIが下書き → 人間が確認）

docsを読んで要約する
Notion DBに記録する下書きを作る
PRの内容から開発メモを作る
障害記録を整理する
記事の下書きを作る
Obsidian用のタグを提案する
「ここは人間の確認が必要」とフラグを立てる

ここはAIが得意な領域です。AIに下ごしらえをしてもらい、人間が最後に確認する。この形が一番、安全で速いです。

🔴 人間がやるべき（＝判断と責任）

何を優先するか決める
本番に公開するか決める
PRをマージするか決める
関係者にどう説明するか決める
情報の扱いを判断する
記事として公開してよいか判断する
失敗から次のルールを作る

AIは案を出せます。でも、責任のある判断は人間がやるべきです。とくに削除・公開・送信・マージ・DB変更は、必ず人間の確認を挟んだ方が安全です。

まとめ

AIと一緒に開発すると、作業スピードは上がります。でも、情報も同じくらい速く増えます。

だからこそ、情報の置き場所を 役割で分ける ことが効いてきます。

置き場所	役割
Notion	いま、どうなっているか
Obsidian	なぜ、そう考えたか
docs	実際の記録
Git	コードの履歴
AI	整理する係
人間	判断する係

AIに全部任せるのではなく、AIに整理してもらい、人間が判断する。

この分担が、個人開発でもチーム開発でも、これからますます大事になると考えています。

質問・誤りの指摘・「うちではこうしている」という事例の共有、いつでも歓迎します。

著者プロフィール

臨床工学技士 × AIエンジニア / 11年間、病院の医療機器の現場に立ち続けてきました。いまはAIエンジニアとしても活動しながら、酪農学園大学の研究生として論文博士の取得を目指しています。研究テーマの主軸は遺伝子医療の未来。そのうえで、医療現場と地続きにある病院のIT・サイバーセキュリティ・医療AI導入についても、現場で起きている課題と一次情報を突き合わせながら調べ続けています。

質問・誤りの指摘・「うちの病院ではこうしている」という事例の共有、いつでも歓迎します。

X：@endoh_taichi
Qiita：@TaichiEndoh

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up