第二の脳の裏側 — GitHub Issuesを1人PMツールにした話

Last updated at 2026-03-05Posted at 2026-03-05

はじめに

前回、Claude Codeで「第二の脳（セカンドブレイン）」を構築した話を書きました。

前回の記事はこちら
https://qiita.com/yamapiiii/items/cc2450f410b64329d275

今回はその裏側。GitHubの機能だけでプロジェクト管理を完結させ、Claude Codeで自動化した話です。

使っているのはGitHubの標準機能だけ。

Issues — 全プロジェクトのタスクを1リポジトリに集約
Milestones — プロジェクト × フェーズで管理
Labels — タスクの種別と優先度
Projects — Board / Roadmap で俯瞰
gh CLI — Claude Codeから全操作を自動化

外部ツールは一切不要でした。

この記事でわかること

GitHub Issues を「全プロジェクト共通のタスクDB」にする設計
Milestone × Label × Projects の命名規則と運用ルール
gh CLI でIssue作成→実行→クローズを自動化する方法
Claude Codeと組み合わせて「プロジェクト管理ごと自動化」する仕組み

対象読者

個人開発でタスク管理に困っている人
GitHub Issues を使いこなしたい人
Claude Codeを使っている or 興味がある開発者
専用ツールは重すぎるが、メモ帳管理は限界な人

全体設計: 1リポジトリに全Issueを集約する

「思考リポ」と「実装リポ」を分ける

brain リポ（GitHub Issues の単一事実源）
├── Issues: 全プロジェクトのタスク
├── Milestones: プロジェクト × フェーズ
├── Projects: 横断ビュー + PJ別ビュー
├── Labels: 種別 × 優先度 × PJ名
└── Markdown: 設計書・意思決定ログ

project リポ（コードだけ）
├── ソースコード
├── PR → brain Issue を参照
└── Issues は作らない ← 重要

なぜ1リポジトリに集約するのか

理由1: 2箇所に分散すると必ずドリフトする

「あのIssue、brainに書いたっけ？projectに書いたっけ？」が発生した時点で管理が崩壊します。brain リポジトリに一元化し、project リポのPRからは参照するだけ。

# project リポの PR description
Closes {owner}/brain#16

GitHub がクロスリポジトリ参照をサポートしているので、PRをマージすると brain 側の Issue が自動クローズされます。

理由2: GitHub Projects が複数リポのIssueをまとめられる

GitHub Projects (V2) は複数リポジトリのIssueを1つのボードに集約できます。つまり、Issueをbrainに一元化しても、プロジェクトごとのビューは自由に作れる。

理由3: gh CLI で一括操作できる

--repo フラグで操作対象を指定するだけ。Issue が散らばっていると、どのリポに gh issue create すればいいか迷う。1リポなら迷わない。

Issues: タスクの書き方

Issue タイトルの命名規則

タイトルの先頭にタスクの種別をprefixとして付けます。

investigate: React vs Next.js vs Remix 比較調査
design:      ダッシュボード画面のUI設計
impl:        ユーザー認証APIの実装
docs:        README作成（初期セットアップ手順）

prefix	意味	いつ使う
`investigate:`	調査	技術選定、市場調査、データ分析
`design:`	設計	アーキテクチャ、画面モック、DB設計
`impl:`	実装	コーディング、環境構築
`docs:`	ドキュメント	資料作成、レポート、プレゼン

なぜ prefix か: Milestone で絞り込んだとき、一覧でタスクの性質が一瞬でわかる。

Issue body の設計: 3回の失敗で辿り着いたフォーマット

最初から今のフォーマットだったわけではありません。3回失敗しました。

v1: タスク名だけ

ベクトルDB構築

何をすれば終わりかわからず、数週間「進行中」のまま放置。

v2: やることリスト

## やること
- Pinecone vs Weaviate vs Qdrant を比較
- 選定してセットアップ
- テストデータを投入

「やること」は書いたが「何をもって完了か」がない。テストデータを1件入れたら完了？100件？

v3: Done条件ドリブン

「やること」ではなく**「終わった状態」を先に定義する**フォーマットに変更。タスクが動き始めた。

しかし、まだ問題があった。「なぜこの Issue をやるのか」「やらなかったらどうなるか」がわからない。オーケストレータが優先度を判断するとき、Done条件だけでは「どれが重要か」が判断できない。

v4（現在）: ゴール / 背景 / 影響 / 範囲 / 完了条件 / 依存

pm_brief.md のプロジェクトレベルの問いを、Issue 1枚1枚にも落とす。AIが自動生成するのでコストはゼロ。むしろ書いてあるほど自動実行の精度が上がる。

共通フレーム: 全 Issue に書く6セクション

## ゴール
{この Issue が完了したとき、世界はどう変わっているか。1-2文}

## 背景
{このタスクが必要な理由}

## 影響
- 実行: {完了した場合のポジティブな影響}
- 放置: {やらなかった場合のネガティブな影響。書けないなら優先度を疑う}

## 範囲
- やること: {具体的なアクション}
- やらないこと: {スコープ外を明示。「ここまではやらない」の境界線}

## 完了条件
- [ ] {チェックボックスで完了条件を列挙}

## 依存
- 影響先: {変更が及ぶファイル・システム・人}
- 先行: {先行 Issue 番号 or "なし"}

---
🧠 Generated by /decompose

各セクションが存在する理由

セクション	誰が読むか	なぜ必要か
ゴール	人間 + AI	Issue一覧で概要を把握。「何を達成するか」の一文
背景	人間 + AI	手段に溺れるのを防ぐ。「そもそも」に立ち返れる
影響（実行/放置）	人間 + AI	実行でインパクトを、放置で優先度を判断。「別に困らない」なら後回し
範囲（やる/やらない）	人間 + AI	やることで作業計画を、やらないことでスコープクリープを防止
完了条件	人間 + AI	「閉じていいか」の判断基準。GitHub UIで進捗バーが出る
依存	AI（オーケストレータ）	ブロッカー検出 + 変更の波及先を事前に把握

特に効くのは「影響 - 放置」と「範囲 - やらないこと」

「影響 - 放置」= 優先度フィルタ

# 優先度が高いIssue
## 影響
- 実行: DB設計が確定し、MS2以降の実装が進む
- 放置: 認証・API・フロント全てがブロックされる。

# 優先度が低いIssue
## 影響
- 実行: ダークモードが使えるようになる
- 放置: 特に困らない。ライトモードのままで問題ない。

放置に「特に困らない」と書いた Issue は、自然と優先度が下がる。オーケストレータもこのセクションを読んで判断する。放置の影響が書けない Issue は、そもそもやる必要がない可能性がある。

「範囲 - やらないこと」= スコープクリープ防止

## 範囲
- やること:
  - 認証ライブラリ3つの比較表を作る
  - 1つに決定する
- やらないこと:
  - 認証機能の実装（次のIssueでやる）
  - OAuth連携の設計（別Issue）
  - ユーザー管理画面の設計

AIに実行させると「ついでにこれもやっておきました」が起きる。やらないことを明示しないと、AIは親切心でスコープを広げる。これが一番厄介。

完了条件の書き方: 「成果物 × 品質基準」

チェックボックス1つにつき**「何がある」+「どんな状態」**の2要素を入れます。

❌ 曖昧:
- [ ] 調査する
- [ ] まとめる

✅ 検証可能:
- [ ] 候補3つの比較表がある（機能・料金・学習コスト）
- [ ] 1つに決定し、選定理由が書かれている
- [ ] サンプルコードで動作確認済み

判定テスト: 第三者がその Issue を見て、「完了している / していない」を5秒で判断できるか？できないなら書き直し。

種別ごとの追加セクション

共通フレームに加えて、種別ごとにセクションを足す。

調査系（`investigate:`）— 「エビデンス要件」を足す

## ゴール
認証ライブラリが1つに決定し、選定根拠が文書化されている状態。

## 背景
MS2でユーザー認証を実装予定。ライブラリ未選定のまま実装に入ると手戻りが大きい。

## 影響
- 実行: 認証実装に迷いなく着手できる。チーム内で判断根拠を共有できる。
- 放置: 実装中に「やっぱり別のにすれば…」が発生し、手戻り。

## エビデンス要件
- 公式ドキュメント・GitHubスター数・npm DL数など客観的データ、出典必須
- 事実と個人の感想を分離

## 範囲
- やること:
  - NextAuth / Clerk / Supabase Auth の3候補を比較
  - 機能・料金・学習コスト・エコシステムの比較表を作成
  - 1つに決定し、選定理由を記述
- やらないこと:
  - 認証機能の実装（次Issue: impl: ユーザー認証）
  - OAuth連携の詳細設計（別Issue）

## 完了条件
- [ ] 3候補の比較表がある（機能・料金・学習コスト・エコシステム）
- [ ] 1つに決定し、選定理由が書かれている
- [ ] サンプルコードで基本動作を確認済み
- [ ] 全データに出典あり

## 依存
- 影響先: 30_Tech_Notes/auth_selection.md に新規レポート追加
- 先行: なし

なぜ「エビデンス要件」が要るか: AIに調査させると「それっぽい嘘」を書く。「出典必須」「事実と感想を分離」と明記することでAIの出力品質が上がる。Issue body はプロンプトでもある。

実装系（`impl:`）— 「問題 / 解決策 / リスク」を足す

## ゴール
ユーザー認証（サインアップ・ログイン・ログアウト）が動作する状態。

## 背景
MS1でDB設計とAPI雛形が完了済み。認証がないとユーザー固有データの保存ができない。

## 影響
- 実行: ユーザーごとのデータ管理が可能になり、MS3のダッシュボード実装に進める。
- 放置: 全機能が「共有データ」のまま。個人利用すらできない。

## 問題
現在すべてのAPIエンドポイントが認証なしでアクセス可能。ユーザーの概念がない。

## 解決策
NextAuth.js を導入し、メール+パスワード認証を実装する。
- サインアップ / ログイン / ログアウトの3画面
- セッション管理（JWT）
- APIルートにミドルウェアで認証チェックを追加

## 範囲
- やること:
  - NextAuth.js のセットアップ
  - サインアップ・ログイン・ログアウト画面の実装
  - APIミドルウェアで認証チェック
- やらないこと:
  - OAuth連携（Google / GitHub ログイン）は次Issue
  - パスワードリセット機能（別Issue）
  - 管理者権限・ロール管理

## 完了条件
- [ ] サインアップでユーザー作成ができる
- [ ] ログイン・ログアウトが動作する
- [ ] 未認証ユーザーがAPIにアクセスすると401が返る
- [ ] テストが通る

## リスク
- セッション管理の方式（JWT vs DB session）で実装コストが変わる
- メール送信基盤が未構築（確認メールは後回し）

## 依存
- 影響先: src/auth/、src/middleware/、全APIルート
- 先行: #12（DB設計確定後）

まとめ: Issue body の設計原則

共通フレーム（全Issue必須）:
  ゴール    — 完了後の状態
  背景      — なぜやるか
  影響      — 実行（やるとどうなる）/ 放置（やらないとどうなる）
  範囲      — やること / やらないこと
  完了条件  — チェックボックスで完了条件
  依存      — 影響先・先行Issue

種別ごとの追加:
  investigate: + エビデンス要件
  impl:        + 問題 / 解決策 / リスク

6セクションは多く見えますが、AI が自動生成するので人間の負担はゼロ。/decompose が roadmap.md と pm_brief.md を読んで、各 Issue に自動展開します。

むしろ、このフォーマットの本当のユーザーは /work で Issue を読んで実行する AI です。背景がないと優先度が判断できない。範囲がないと余計なことをする。完了条件がないと終われない。

Issue body は AI へのプロンプトである。 テンプレートの設計は、プロンプトエンジニアリングそのもの。

Milestones: プロジェクト × フェーズ

命名規則

[プロジェクト名] MS番号 or Phase番号: 概要

例えばこんな感じです:

[my-app] MS1: 基盤 - DB設計 + API雛形              (0 open / 5 closed) ✅
[my-app] MS2: 認証 - ログイン・サインアップ         (3 open / 1 closed)
[my-app] MS3: ダッシュボード - メイン画面           (4 open / 0 closed)
[tech-blog] MS1: 環境構築 - Next.js + MDX           (0 open / 3 closed) ✅
[tech-blog] MS2: デザイン - トップ + 記事ページ     (2 open / 0 closed)
[reading] MS1: 読了5冊 - 技術書の要約ノート         (1 open / 4 closed)

なぜこの形式か:

[プロジェクト名] が先頭にあるので、gh CLI でフィルタしやすい
MS番号 or Phase番号 で順序がわかる
概要 で「何がデモできるか」が一文でわかる

Milestone の切り方: 「デモできるか？」テスト

そのMSが完了した時点で、誰かに「見て、こうなった」とデモできるか？

✅ 「ログインしてダッシュボードが見える」 → デモできる → 良いMilestone
❌ 「DB設計が終わった」 → デモできない → まだ「作業の塊」

`gh` CLI での Milestone 作成

gh api repos/{owner}/brain/milestones \
  -f title="[my-app] MS2: 認証 - ログイン・サインアップ" \
  -f description="メール+パスワードでログインできる状態" \
  -f due_on="2026-04-15T00:00:00Z"

Labels: 種別 × 優先度の2軸

実際のラベル設計

種別ラベル（タスクの性質）:

Label	色	用途
`investigation`	🟣 purple	調査・選定タスク
`implementation`	🟢 green	実装タスク
`design`	🔵 blue	設計タスク
`documentation`	🔵 light blue	ドキュメント作成

優先度ラベル:

Label	色	用途
`priority: high`	🔴 red	緊急・重要
`priority: medium`	🟡 yellow	中程度の優先度
`priority: low`	🟢 green	低優先度・いつでもOK

プロジェクトラベル（横断検索用）:

Label	用途
`my-app`	メインの個人開発アプリ
`ai-generated`	AIが自動生成したIssue
`idea`	アイデアから生まれたIssue

ラベルの初期セットアップ

# 種別ラベル
gh label create "investigation" --description "調査・選定タスク" --color "d4c5f9" --repo {owner}/brain
gh label create "implementation" --description "実装タスク" --color "0e8a16" --repo {owner}/brain
gh label create "design" --description "設計タスク" --color "1d76db" --repo {owner}/brain

# 優先度ラベル
gh label create "priority: high" --description "緊急・重要" --color "d73a4a" --repo {owner}/brain
gh label create "priority: medium" --description "中程度の優先度" --color "fbca04" --repo {owner}/brain
gh label create "priority: low" --description "低優先度" --color "0e8a16" --repo {owner}/brain

# プロジェクトラベル
gh label create "my-app" --description "メインPJ" --color "fbca04" --repo {owner}/brain

「調査」と「実装」を分けるのが最重要

❌ - impl: ベクトルDB構築（調査と実装が混ざっている）

✅ - investigate: ベクトルDB選定（比較表を作って1つに決定）
   - impl: ベクトルDB環境構築（選定結果に基づいて構築）

ラベルで investigation と implementation を明示的に分けることで、見積もりが崩壊しなくなります。

GitHub Projects: ボードで俯瞰する

プロジェクトの作り方

例えば3つの個人プロジェクトを抱えているなら:

#	Project	Items	用途
1	ALL VIEW	30	全Issue横断ビュー
2	My App	15	メインの個人開発
3	Tech Blog	8	技術ブログ
4	Reading Notes	5	読書ノート

使い分け

ALL VIEW: 全プロジェクト横断。「今週やるべきこと」を俯瞰
個別プロジェクト: そのプロジェクトの Board / Roadmap ビュー

GitHub Projects V2 は複数リポのIssueを混ぜられるので、brain リポの Issue と project リポの PR を同じボードに並べられます。

gh CLI × Claude Code: 自動化の実装

ここからが本題。上記のGitHub設計を、Claude Codeでどう自動化しているかです。

`/decompose` — タスク分解 → Issue 一括作成

「プロジェクト名を伝えるだけで、ゴール → MS → タスクに分解し、GitHub Milestone + Issue を自動作成する」コマンド。

裏で実行される gh コマンド:

# Step 1: Milestone 作成
gh api repos/{owner}/brain/milestones \
  -f title="[my-app] MS2: 認証 - ログイン・サインアップ" \
  -f description="メール+パスワードでログインできる状態" \
  -f due_on="2026-04-15T00:00:00Z"

# Step 2: Issue 作成（Milestone + Label 付き）
gh issue create --repo {owner}/brain \
  --title "investigate: 認証ライブラリ比較調査" \
  --label "investigation,my-app" \
  --milestone "[my-app] MS2: 認証 - ログイン・サインアップ" \
  --body "$(cat <<'EOF'
## ゴール
認証ライブラリが1つに決定し、選定根拠が文書化されている状態。

## 完了条件
- [ ] 3候補の比較表がある
- [ ] 1つに決定し、選定理由が書かれている
- [ ] サンプルコードで動作確認済み

## 依存
- 先行: なし

---
🧠 Generated by /decompose
EOF
)"

私の場合、/decompose my-app 一発で、5 Milestones + 18 Issues を自動作成できました。

`/work` — Issue を読んで実行してクローズ

「Issue 番号を伝えるだけで、内容を読んで実行し、完了報告してクローズする」コマンド。

# Step 1: Issue 取得
gh issue view 15 --repo {owner}/brain --json title,body,labels,milestone

# Step 2: （Claude Code がタスクを実行）

# Step 3: 完了コメント
gh issue comment 15 --repo {owner}/brain --body "$(cat <<'EOF'
## Completed

### 成果物
- NextAuth / Clerk / Supabase Auth の比較表を作成
- NextAuth.js に決定、選定理由を記述
- 30_Tech_Notes/auth_selection.md に保存

### 作業内容
- 3候補の公式ドキュメント・GitHubリポを調査
- 機能・料金・学習コスト・エコシステムの4軸で比較
- サンプルコードで基本動作を確認

---
🤖 Completed by Claude Code
EOF
)"

# Step 4: クローズ
gh issue close 15 --repo {owner}/brain

Issue のライフサイクル例:

作成: /decompose で自動生成
  ↓ 約20分
完了: /work #15 で自動実行
  Comment: "認証ライブラリ比較完了。NextAuth.jsに決定。"
  State: CLOSED

約20分で調査 → 比較表作成 → 決定 → レポート保存 → Issue クローズ。人間がやったのは /work #15 と打っただけ。

`/orchestrate` — 優先度判定して連続実行

「Milestoneを指定すると、Issue の優先度を自動判定して順番に実行する」コマンド。

# Step 1: Milestone のIssueを取得
gh issue list --repo {owner}/brain \
  --milestone "[my-app] MS2: 認証 - ログイン・サインアップ" \
  --state open \
  --json number,title,labels

# Step 2: 優先度スコアリング
# Score = (依存関係 × 3) + (ラベル優先度 × 2) + (タイプ適合度 × 2) + (工数 × 1) + (鮮度 × 1)

# Step 3: 上位3件を順次 /work で実行
# Step 4: roadmap.md を更新
# Step 5: Git commit

ガードレール:

max_issues_per_chain: 3        # 1チェーンで最大3Issue
max_time_per_issue: 10min      # 1Issue最大10分
max_time_per_chain: 30min      # 1チェーン最大30分
forbidden_actions:
  - ファイル削除
  - force push
human_interaction:
  max_questions_per_chain: 1    # 人間への質問は最大1回

`/issue` — 自然言語から構造化Issue作成

> /issue ダークモードを追加したい

→ Claude Code が以下を自動判定:
  タイトル: impl: ダークモード対応
  ラベル: implementation, my-app
  Milestone: 候補を提示（or 新規作成）

→ gh issue create で作成

`/weekly-review` — Milestone 進捗の自動チェック

# 全Milestoneの進捗を取得
gh api repos/{owner}/brain/milestones --paginate \
  --jq '.[] | "\(.title)\t\(.open_issues)/\(.closed_issues)"'

# 出力例:
# [my-app] MS1: 基盤 - DB設計 + API雛形        0/5  ✅ 完了
# [my-app] MS2: 認証 - ログイン・サインアップ   3/1  🔄 進行中
# [tech-blog] MS1: 環境構築                    0/3  ✅ 完了
# [tech-blog] MS2: デザイン                    2/0  ⚠️ 未着手

週次レビューでは、この進捗データにPM視点のヘルスチェックが自動追加されます:

## PMヘルス診断

| プロジェクト | MS進捗 | 健康度 | 直近活動 |
|---|---|---|---|
| my-app | MS1完了、MS2進行中 | 🟢 | 2日前 |
| tech-blog | MS1完了、MS2未着手 | 🟡 | 1週間前 |
| reading | MS1残り1件 | 🔴 | 30日前 |

### キャパシティ
- Active: 3個 / 推奨上限: 5個 ✅

### 停滞プロジェクト
- reading: 1ヶ月間活動なし。興味が薄れた可能性。
  提案: 本のジャンルを絞って再開 or アーカイブ

クロスリポジトリ連携: brain Issue ↔ project PR

brain Issue を project PR から参照する

# project リポで PR を作る
gh pr create \
  --title "feat: ユーザー認証API実装" \
  --body "Closes {owner}/brain#16"

PR がマージされると、brain リポの Issue #16 が自動クローズされます。

実際のフロー

ポイント: Claude Code は brain リポの Issue を読み、project リポで実装し、PR 経由で brain Issue をクローズする。2つのリポジトリを跨いだワークフローが gh CLI で完結します。

運用してみて

良かったこと

「今何をすべきか」に迷わない: Milestone の open Issue を見れば、次にやることが明確
サボっても復帰しやすい: 1ヶ月放置しても、Issue を読めば「ここまでやった、次はこれ」がわかる
AIに丸投げできる: /work #15 と打つだけで、Issue の内容を読んで実行してクローズしてくれる
命名規則のおかげで検索が楽: gh issue list --label investigation で調査系だけ一覧

想定される規模感

指標	目安
プロジェクト数	3〜5個が管理しやすい
Issue数	プロジェクトあたり10〜30件
Milestone数	プロジェクトあたり3〜6個
Labels	種別4 + 優先度3 + PJ名 = 10〜15種類

学んだこと

1. GitHub Issues は「タスクDB」として十分強い

Labels でフィルタ、Milestones でグルーピング、Projects でビュー切替。個人〜小規模チームなら、これ以上のツールは要らない。

2. `gh` CLI が自動化の鍵

Claude Code × gh CLI の組み合わせで、Issue 作成・コメント・クローズが全自動化できる。GUI を使う必要がほぼなくなった。

3. 命名規則を最初に決めると全部楽になる

[project] MSn: description と type: title のフォーマットを最初に決めたおかげで:

Issue 一覧でタスクの性質が一瞬でわかる
Milestone でプロジェクト横断のフィルタができる
AIが命名規則を学習して、一貫した Issue を生成してくれる

4. 「1リポに全Issue」は最初に決める

後から統合するのは大変。最初から「Issues は brain リポに一元化」と決めておくのが最重要。

5. 完了条件で Issue が止まらなくなる

Issue body に完了条件をチェックボックスで書くだけで、「何をすれば閉じていいか」が明確になる。GitHub の UI でもチェックボックスの進捗が表示されるので、管理しやすい。

はじめ方: 最小構成

Step 1: brain リポを作り、ラベルを設定

gh repo create brain --private
cd brain && git init

# 最低限のラベル
gh label create "investigation" --color "d4c5f9"
gh label create "implementation" --color "0e8a16"
gh label create "design" --color "1d76db"
gh label create "priority: high" --color "d73a4a"
gh label create "priority: medium" --color "fbca04"

Step 2: 最初の Milestone と Issue を作る

# Milestone
gh api repos/{owner}/brain/milestones \
  -f title="[my-project] MS1: MVP" \
  -f description="最小限の機能が動く状態"

# Issue
gh issue create \
  --title "investigate: 技術選定" \
  --label "investigation" \
  --milestone "[my-project] MS1: MVP" \
  --body "## Done条件
- [ ] 候補3つの比較表がある
- [ ] 1つに決定している"

Step 3: GitHub Projects でボードを作る

gh project create --title "My Project" --owner @me

ここまで5分。あとは Issue を書いて、消化して、閉じるだけ。

Claude Code を使っているなら、CLAUDE.md に以下を追加するだけで Issue ベースのワークフローが動き始めます:

## ルール
- タスクは GitHub Issues で管理する（リポ: brain）
- Issue の Done条件が全て満たされたら gh issue close する
- 新しいタスクは gh issue create で作成する

まとめ

GitHub機能	使い方	自動化
Issues	全PJのタスクを brain リポに集約	`/decompose` で一括作成
Milestones	`[project] MSn: 概要` で管理	`gh api` で自動作成
Labels	種別(4種) × 優先度(3段) × PJ	`gh label create` で初期化
Projects	Board / Roadmap で俯瞰	`gh project create`
gh CLI	全操作をCLIで実行	Claude Code が自動実行
Cross-repo	PR → `Closes brain#N`	Issue 自動クローズ

Claude Code と gh CLI を組み合わせれば、そのルールの運用すら自動化できる。

前回の記事: Claude Codeで「第二の脳」を構築した話
https://qiita.com/yamapiiii/items/cc2450f410b64329d275

質問はコメント欄でお気軽にどうぞ。

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