Cowork で 4 技術並行学習｜モダリティ別の記録術

第 1 回: Cowork 機能マップ 2026年5月版 — 個人インフラエンジニアの活用 5 パターンではパターン 2「4 技術並行学習の記録」として、Cowork がどの場面で機能するかを概観しました。

第 2 回: Hyper-V ホームラボに Cowork を組み込むでは、HomeLab 親プロジェクトとフォルダ構造（HomeLab\{_memory, iac, logs, docs}\）・命名規約を確立しました。

本記事はその続きとして、VMware VCF9・Google Cloud・Payara・Kubernetes という 4 技術を同時に学び続けるための「プロジェクト二段構成」と「モダリティ別の記録術」を整理します。

ここでいう「モダリティ」とは、技術ごとの学習の進め方（様式）を指します。本シリーズは進め方を 3 つに分類し、第 1 回と同じく Mode A / B / C と表記します。

Payara・Kubernetes は手元の Linux VM で実機操作するMode A（ローカルハンズオン）、Google Cloud は無料枠で操作するMode B（クラウド無料枠ハンズオン）、VMware VCF9 は資料読解が主体のMode C（ドキュメント学習中心）に当たります。

HomeLab を残しつつ技術別サブプロジェクトを足す — 二段構成の設計

第 2 回で作成手順を示した HomeLab プロジェクト（Project）は、本記事でも解体せずそのまま使います。ホスト環境・命名規約・IaC ツール選定・やってはいけないことといった「共通前提」をここに置き続けることで、技術別の作業に入るたびに一から前提を書き直すコストを避けられます。

技術別の試行錯誤は別プロジェクトに任せます。HomeLab 親プロジェクトを「共通前提のメモリ（Memory）置き場」として残し、4 技術それぞれにサブプロジェクトを追加するのが「二段構成」と呼ぶ設計です。

メモリはプロジェクト間で共有されない

二段構成で最初に把握しておくべき仕様があります。メモリはプロジェクトにスコープされており、別プロジェクトには持ち越されません。

HomeLab プロジェクトの _memory/memory.md に書いた内容は、技術別サブプロジェクトからは自動では参照されません（Claude Help Center「Organize your tasks with projects in Claude Cowork」, 2026-05-03 確認）。

この制約への実用的な対応は 2 通りあります。(a) HomeLab プロジェクトに割り当てたフォルダ全体（C:\Users\<ユーザー名>\HomeLab\）をサブプロジェクト側でもフォルダスコープ（Folder Scope）に指定し、インストラクションで「_memory/memory.md を参照する」と明示します。

(b) 共通前提のうちそのサブプロジェクトに必要な部分を、サブプロジェクト側の memory.md に転記してから使います。本記事では (a) を主軸とし、(b) はオプションとして示します。

サブプロジェクトの追加手順と命名

Claude Desktop 左ナビの「Projects」セクション右上「+ New project」から追加します。「Use an existing folder」を選び、フォルダスコープには HomeLab\ フォルダ全体を指定する方法が最も手順が少ないです。

プロジェクト名は以下の命名例に合わせます。

プロジェクト名（例）	フォルダスコープ	主な作業
HomeLab	HomeLab\（全体）	共通前提・横断的な問い合わせ
homelab-payara	HomeLab\（インストラクションで payara に絞る）	Hyper-V 上 Linux VM での Payara 試行錯誤（Mode A）
homelab-k8s	同上（k8s に絞る）	k3s / kubeadm 構築ログ・manifest 差分（Mode A）
homelab-gcp	同上（gcp に絞る）	gcloud 操作ログ・クレジット管理（Mode B）
homelab-vcf9	同上（vcf9 に絞る）	公式ドキュメント要点抽出（Mode C）

サブプロジェクトのインストラクション例

各サブプロジェクトのインストラクション冒頭に以下のような宣言を置くと、Cowork が毎セッションの起動時に共通前提と技術固有のスコープを両方把握した状態で動きます。

私は個人インフラエンジニア。本プロジェクトは Hyper-V ホームラボでの Payara ハンズオン学習に特化する。
親プロジェクト HomeLab の共通前提は HomeLab\_memory\memory.md に記述している。
毎セッション開始時にそのファイルを読んでから作業を始めること。

学習モダリティ: Mode A（ローカルハンズオン、Hyper-V 上 Linux VM）
主な作業フォルダ:
- HomeLab\logs\payara\  : 試行錯誤ログ（YYYY-MM-DD-<keyword>.md 命名）
- HomeLab\docs\payara\  : 設計メモ・要点抽出
- HomeLab\iac\ansible\playbooks\payara\  : Ansible playbook（参照のみ。編集は IaC プロジェクトで）

ログ記述の固定フォーマット:
1. 目的
2. 実行コマンド
3. 出力（抜粋）
4. エラーメッセージ（あれば）
5. 仮説
6. 次にやること

出力は日本語。破壊的操作は事前確認。認証情報は memory.md・コードに直書きしない。

サブプロジェクト用 memory.md テンプレート

# Payara Project Memory

## 親プロジェクトとの関係
親プロジェクト HomeLab の memory.md を参照する。共通前提（ホスト環境・IaC 選定・命名規約）は親側に集約。

## このプロジェクトの守備範囲
- Hyper-V 上 Linux VM での Payara ハンズオン
- Payara のデプロイ・設定変更・障害再現の試行錯誤ログ蓄積
- 月次で「学習サマリ生成」スキルを実行して docs/payara/_summary/ に出力

## 現在進行中の課題
（セッション末の追記提案で随時更新）

## 学習対象 VM
- payara-app-01（Hyper-V 上 Linux VM、命名規約は親 memory 参照）

## やってはいけないこと
- 親プロジェクト HomeLab の memory.md を本プロジェクトから書き換えない
- iac/ansible/playbooks/payara/ への直接編集（IaC ループは第 4 回のスコープ）

プロジェクトの切り替えは左ナビの Projects セクションを 1 クリックするだけで行えます。ただし Cowork がタスクを生成中に切り替えると、2026 年 5 月 3 日時点で UI 表示の不具合が報告されています。

生成が完了してから切り替えるのが無難です。

Mode A — ローカルハンズオン（Payara・Kubernetes）の試行錯誤ログ術

Payara と Kubernetes は Hyper-V 上の Linux VM でフルハンズオンができます（Mode A）。学習の主体はコマンド実行と出力確認であり、エラーが出るたびに仮説を立てて再試行するサイクルが回ります。

このサイクルを記録に残さないと、数週間後に同じエラーで同じ時間を消費することになります。

ログファイルの命名と保存場所

第 2 回で確立した命名規約（YYYY-MM-DD-<keyword>.md）をそのまま継承します。保存先は HomeLab\logs\<技術名>\ 配下。

HomeLab\logs\kubernetes\2026-05-02-kubeadm-init-fails-cgroup.md
HomeLab\logs\kubernetes\2026-05-03-coredns-pending-pod.md
HomeLab\logs\payara\2026-05-03-jdbc-pool-creation-fails.md

1 ファイルの固定フォーマット

ファイル内の構造を固定することで、後から Cowork のスキルが安定して月次サマリを生成できる状態になります。以下の 6 項目をそのまま見出しとして使います。

1. 目的: 今日この試行で何を確かめようとしたか
2. 実行コマンド: ターミナルに打ったコマンドをそのまま貼る
3. 出力（抜粋）: 成功・失敗を問わず関係する行を貼る（全量は不要）
4. エラーメッセージ（あれば）: エラー全文をコピーして貼る
5. 仮説: なぜこうなったかの自分なりの見立て
6. 次にやること: 次セッションで最初にやるべき 1 アクション

Cowork のサブプロジェクト（homelab-k8s など）を開いた状態でこのフォーマットに沿って書くと、「前回の続き」を尋ねたときに Cowork が「次にやること」セクションを読んで文脈を復元します。毎回ゼロから説明し直す手間が減ります。

「失敗から学ぶ」蓄積 — _lessons.md の運用

ログが 10 本以上溜まってきたら、月末に Cowork に「今月の logs/kubernetes/ のエラーを抽出して docs/kubernetes/_lessons.md に追記して」と依頼します。追記の内容は「エラー種別 → 原因 → 再発防止策」の 3 段で整理させます。

次回以降、同系統のエラーが出たときに「_lessons.md に似た事例がないか確認して」の一言で過去の知見を呼び出せます。

playbook や manifest の差分レビューも Cowork に依頼できますが、IaC を Cowork に育てさせる本格的なループは第 4 回: OpenTofu と Ansible のコードを Cowork に育てさせるで扱います。本記事では「ログを蓄積する」段階に留めます。

Mode B — クラウド無料枠ハンズオン（GCP）の記録運用

Google Cloud はローカルに VM を立てる必要がなく、gcloud CLI とブラウザコンソールで操作します（Mode B）。無料枠の $300 スタートアップクレジットを使い切らずに学習を進めるクレジット管理が、Mode A にはない特有の課題となります。

クレジット使用量管理

週次で以下のコマンドを実行し、出力を docs\gcp\credit-ledger.md の末尾に追記する運用を最初に設定しておきます。gcloud 認証は事前に gcloud auth login を済ませた前提です。

gcloud billing accounts list
gcloud billing budgets list --billing-account=<ACCOUNT_ID>

手動で実行するのを忘れがちな場合は、スケジュールタスク（Scheduled Task）の weekly 頻度でこの追記を Cowork に委ねる形にします。スケジュールタスクの詳細は後述の「Cowork 機能で並行学習を維持する」で扱います。

gcloud とコンソールの併用記録

GCP コンソール（ブラウザ）と gcloud CLI を行き来する場面では、コンソール操作の内容もログファイルに 1 行テキストで記録します。

# ログ例: HomeLab\logs\gcp\2026-05-03-cloud-run-first-deploy.md

## 目的
Cloud Run に初めてコンテナをデプロイして動作を確認する

## 実行コマンド
gcloud run deploy hello-run \
  --image gcr.io/<PROJECT_ID>/hello-app:v1 \
  --region asia-northeast1 \
  --allow-unauthenticated

## 出力（抜粋）
Deploying container to Cloud Run service [hello-run] in project ...
✓ Deploying... Done.
Service URL: https://hello-run-xxxx-an.a.run.app

## GCP コンソール操作（補足）
Cloud Run > hello-run > 「ログ」タブで起動ログを確認。リクエスト受信の行が出ていることを確認。

## 次にやること
tofu plan を書いて同じリソースを IaC 化する（詳細は #04 に委ねる）

OpenTofu の tofu plan / tofu apply 出力の構造化保存も同様に logs\gcp\ に残します。IaC を Cowork で育てる具体的なサイクルは第 4 回に委ねます。

本記事では「ログに残す」ところまでを担います。

GCP のスコープは Cloud Run・Compute Engine・Cloud Storage など学習コストの低いサービスに絞ります。BigQuery やデータ系・生成 AI 系のサービスは本シリーズでは扱いません。

Mode C — ドキュメント学習中心（VCF9）の Cowork 活用と限界

VMware Cloud Foundation 9（VCF9）は個人のホームラボでフルハンズオンを組むのがライセンス費用の面で困難なため、公式ドキュメントや VMware Explore のセッション資料 PDF を読み込む「ドキュメント学習中心」（Mode C）が主体となります。

PDF の配置と Cowork での活用

公式ドキュメントや PDF 資料は HomeLab\docs\vcf9\_sources\ に置きます。homelab-vcf9 プロジェクトのフォルダスコープに HomeLab\ を指定し、インストラクションで docs\vcf9\ 配下を主な作業領域と宣言しておくと、Cowork がフォルダ構造を把握した状態で動きます。

Cowork が向く局面は単発タスク型です。「この章の用語を整理して docs\vcf9\glossary.md に保存して」「_sources\vcf9-networking-guide.pdf から NSX-T に関連する設定値を抜き出して」といった問い合わせに応える形で使います。

抽出結果を docs\vcf9\<topic>.md として保存する前に、Cowork は確認を求めてきます（承認後に書き込む仕様）。

Cowork 機能で並行学習を維持する — スキル・スケジュールタスク・メモリ更新

プロジェクト分離とログ蓄積の仕組みを整えたあとも、4 技術を並行して学び続けるうえで 3 つの運用課題が残ります。コンテキストスイッチのコスト・学習ペースの偏り・過去成果の埋没、の 3 つです。

Cowork のスキル（Skill）・スケジュールタスク（Scheduled Task）・メモリ更新フローはこれらの緩和に使えます。

個人スキルの作り方 — SKILL.md 最小構成

スキルは「Claude を自分の作業スタイルに合わせて拡張する再利用可能な指示セット」です。カスタムスキルのインストールは Pro 以上が前提です。

最小構成は SKILL.md 1 ファイルで、先頭に YAML frontmatter を置きます。

---
name: monthly-learning-summary
description: |
  指定フォルダ配下の当月分学習ログ（YYYY-MM-DD-*.md）を読み込み、
  技術ごとに「試行した内容・解決したエラー・残課題」の 3 項目で月次サマリを生成する。
  毎月末に手動で呼び出す想定。出力先は docs/<技術>/_summary/YYYY-MM.md。
---

## 手順

1. `logs/<技術>/` 配下の今月分ファイル（ファイル名に YYYY-MM が含まれるもの）を一覧取得する
2. 各ファイルの「エラーメッセージ」「仮説」「次にやること」セクションを抽出する
3. 技術ごとに以下の形式でまとめる:
   - 試行した内容（箇条書き）
   - 解決したエラー（エラー種別と原因を 1 行ずつ）
   - 残課題（「次にやること」の未完了分）
4. `docs/<技術>/_summary/YYYY-MM.md` に書き込む前に内容を提示し、承認を得てから書き込む

name は 64 字以下・小文字英数字とハイフンのみ・予約語（anthropic / claude など）は使えません。description には「何をするか」と「いつ使うか」の両方を書くと、Cowork がこのスキルを適切な場面で呼び出しやすくなります。

作成後は Claude Desktop の「Customize > Skills」でインストールし、ON に切り替えて有効化します。

スケジュールタスクで並行学習を維持する

スケジュールタスクの頻度は 5 種類あります: hourly（毎時）/ daily（毎日）/ weekly（毎週）/ weekdays（平日）/ manual（手動実行）。作成は左ナビ「Scheduled」セクション右上「+ New task」か、任意のチャットで /schedule コマンドを入力して誘導に従う方法の 2 通りがあります。

並行学習の維持に使えるタスクの代表例を 2 つ示します。

週次学習進捗レポート（weekly）: 毎週末に logs/ 配下の今週分ファイルを技術別に集計し、どの技術に何本のログがあったかを docs/_weekly/YYYY-WW.md に出力します。学習時間の偏りを数字で把握できます。

今週（月曜〜日曜）に作成された logs/ 配下のファイルを技術別（payara / kubernetes / gcp / vcf9）に集計してください。
各技術のファイル数と「次にやること」セクションの最終行を抽出し、
docs/_weekly/<YYYY-WW>.md に以下の形式で書き込んでください（書き込み前に内容を確認します）:

| 技術 | 今週のログ数 | 直近の「次にやること」 |
|------|------------|----------------------|
| payara | N | ... |
...

クレジット残高更新（weekly）: 前述の GCP クレジット管理コマンドを週次で実行し、出力を docs/gcp/credit-ledger.md に追記します。

メモリ更新フロー — Cowork は勝手に書かない

Cowork はメモリ（Memory）に勝手に書き込みません。セッションの末尾や、ユーザーが「memory に保存して」と依頼したタイミングで「このセッションで判明した事実を memory.md に追記すべき候補」を提示し、ユーザーが承認してから書き込みます。

この確認フローの目的は、古い前提が memory.md に積み重なるのを防ぐことにあります。技術別サブプロジェクトの memory.md は「現在進行中の課題」セクションを持つテンプレートを前述しました。

各セッション末にそのセクションを更新する提案が来るように、インストラクションに「セッション終了時は memory.md の『現在進行中の課題』を更新候補として提示する」と書いておきます。

memory.md が長くなると Cowork が一部を読み落とす傾向があります。HomeLab 親プロジェクトの memory.md も各技術サブプロジェクトの memory.md も、それぞれ 50 行程度を目安に保ち、詳細は _memory/<topic>.md のサブファイルに逃がします。

並行学習の運用課題と緩和策のまとめ

課題	Cowork での緩和策	使う機能
コンテキストスイッチのコスト（技術を切り替えるたびに前提を思い出す時間がかかる）	技術別サブプロジェクトの memory.md「現在進行中の課題」セクションを常に最新に保ち、Cowork が起動時に読む形にする。切り替えは左ナビ 1 クリック	プロジェクト・メモリ
学習ペースの偏り（興味の波で特定技術に集中しすぎる）	週次スケジュールタスクで技術別ログ数を集計し、今週まだログが 0 本の技術を可視化する	スケジュールタスク
過去成果の埋没（数週間前に解決した同じエラーに今日また時間を使う）	月次で「学習サマリ生成」スキルを走らせ、_lessons.md にエラーと再発防止策を蓄積。次回エラー時に「_lessons.md に似た事例がないか」と問い合わせる	スキル・フォルダスコープ

まとめと次回予告

本記事で整理したことを振り返ります。

• HomeLab 親プロジェクトを解体せず、技術別サブプロジェクトを追加する「二段構成」が 4 技術並行学習の出発点になります
• メモリはプロジェクト間で共有されないため、サブプロジェクトのインストラクションに「親の memory.md を読む」指示を明示します
• Mode A（Payara・Kubernetes）は固定フォーマットのログを logs/<技術>/YYYY-MM-DD-<keyword>.md に積みます。月次でスキルに要約させます
• Mode B（GCP）はクレジット管理とコマンド出力の記録が Mode A に加わります。スケジュールタスクで週次集計を自動化できます
• Mode C（VCF9）は単発の抽出・要約に Cowork を使い、PDF 束ね検索と音声化は NotebookLM に任せる役割分担が合理的です
• スキル・スケジュールタスク・メモリ更新フローを組み合わせると、コンテキストスイッチ・偏り・成果埋没という並行学習の 3 課題を緩和できます

次回の第 4 回: OpenTofu と Ansible のコードを Cowork に育てさせるでは、本記事で示した logs/ と docs/ の記録術を、IaC コードの育成サイクルに接続する方法を整理します。

tofu plan / tofu apply の出力を Cowork に食わせ、playbook と manifest を反復的に改善するループが主軸となります。

その先の第 6 回: ホームラボの検証ログを技術ブログ記事に変換するでは、本記事の記録術にそって蓄積した logs/ ファイルを入力に、Cowork が Gutenberg ブロック形式の記事 HTML を出力するフローを扱います。試行錯誤のログが記事の素材として機能する設計になっています。