この記事でわかること
- ✓Claude Code（AIコーディングツール）でサイトを作る実際の流れ
- ✓CLAUDE.mdによるコンテキスト設計の重要性と書き方
- ✓Web Componentsで共通パーツを管理する方法
- ✓AIと人間の役割分担で起きた成功と失敗
なぜ育休中にポートフォリオを作ったか
きっかけは3つ重なった。
ひとつは自分の経歴を整理して「見せられる場所」を作りたかったこと。IT歴13年・プロジェクトリーダーという経験があっても、それを伝える場所がなかった。自分のサイトがあれば、必要なときにURLを渡せる。
もうひとつはリベシティでの名刺。加入したコミュニティで「どんな人か」を伝えるとき、テキストで自己紹介するより、サイトのURLを渡した方が伝わる情報量が段違いだ。
最後は育休という時間。4人目の子ども（双子）が生まれてから育休に入った。新生児の世話は大変だが、断片的にまとまった時間が取れる。その時間で「形になるもの」を作りたかった。
この記事を読む前に
この記事はポートフォリオサイト（あなたが今見ているこのサイト）を作った実録です。「Claude Codeで実際に何ができるのか」を具体例つきで伝えることが目的なので、成功体験だけでなく失敗や手戻りも正直に書きます。
Claude Code とは何か（1分で理解する）
普通の AI チャット
質問に答えてくれる。コードも書いてくれる。でも実行はしない。ファイルも触らない。自分でコピペする必要がある。
Claude Code
ターミナルで動くAI。コードを書くだけでなく、ファイルを読み・書き・コマンドを実行する。「このページを作って」と言うと本当に作ってくれる。
一言で言えば「ターミナルの中で動く、コードが書けて実行もできるAIアシスタント」だ。
AIエージェントの分類で言うと「自律性レベル3〜4」に相当する。指示を与えれば複数ファイルをまたいで考え、自分でコマンドを実行しながら実装を進める。詳しい解説はAIエージェントとは何かに書いたので、気になる方はそちらも。
いちばん大事だった「コンテキスト設計」
最初に一番時間をかけたのは、コードを書くことではなく「AIに何を渡すか」の設計だった。
ポートフォリオサイトを作るには、まず「自分の情報」が必要だ。経歴・スキル・実績・プロフィール。これをAIに毎回説明していたら効率が悪いし、ページごとに情報がブレる。
解決策：.docs/ フォルダに素材を集約する
# gitignore対象・非公開素材
.docs/
├── profile.md ← 自己紹介・キャッチコピー・設計哲学
├── career.json ← キャリア3期間の構造化データ
├── skills.json ← 技術スキル・資格・対応領域
└── site-config.json ← サイト設定・SNSリンク等
ここにデータを置いておけば、「About ページを作って」と頼むだけで Claude Code が .docs/ を読んで内容を反映してくれる。情報の一元管理が、ページ間の一貫性を保つ鍵だった。
もうひとつの鍵：CLAUDE.md にルールを書く
Claude Code はプロジェクトルートの CLAUDE.md を毎回自動で読む。ここに「会社名を出さない」「地域名を出さない」「スタイルはTailwindで書く」といったルールを書いておくと、指示のたびにルールを説明しなくて済む。
# CLAUDE.md（抜粋）
## 絶対ルール（違反厳禁）
1. 会社の固有名詞（社名）を出力に含めない
2. 地域を特定できる固有名詞を出力に含めない
3. 具体的な年収・資産額を出力に含めない
...
ポイント
「AIに何をやらせるか」の前に「AIに何を渡すか・何を禁じるか」を設計する。これがあるとないとでは、作業効率と出力品質が全然違う。
実際の開発の流れ——うまくいったこと・失敗したこと
設計が終わったら、あとは Claude Code に指示を出しながら実装を進める。順調にいったことと、そうでなかったことを正直に書く。
うまくいったこと
Web Components で共通パーツを作った
「20ページ以上あるのにナビゲーションを全ページに書くのは非効率」と相談したら、Web Components（<site-nav> / <site-footer>）を提案してきた。これで assets/components.js 1ファイルを修正するだけで全ページに反映される。
.docs/ のデータを読んで正確に反映してくれる
「About ページを作って」と言うだけで、skills.json・career.json・profile.md を自分で読んで内容を反映してくれる。指示が短くても、質が高い。
「動くものを見せてから改善」のサイクルが速い
デザインの好みは言葉では伝えにくい。でも動いているものを見て「このセクションをもっとコンパクトに」「色味がちょっと違う」と言えば、すぐ直る。
失敗・手戻りしたこと
最初は素材なしで頼んで、架空の情報が生成された
.docs/ を整備する前に「とりあえず About ページを」と頼んだら、AIが適当な情報を補完してしまった。素材の準備が先、実装は後——この順番が大事だと気づいた。
データの精度が出力の精度に直結する
skills.json に「PostgreSQL：1年」と書いていたら、About ページにも「1年」と表示された。実際は4年だった。AIは忠実に素材を反映するので、素材が間違っていれば出力も間違う。ゴミを入れればゴミが出る（Garbage in, garbage out）。
指示があいまいだと意図と違うものができる
「もっとかっこよくして」という指示では何も伝わらない。「スキルバーをプログレスバーからタグ一覧に変えて」のように、変更箇所・変更内容・理由をセットで伝えると一発で通る。
できあがったもの
20+
総ページ数
9
Lab 記事数
13
整理した資格数
4
実績プロジェクト
インフラは AWS S3 + CloudFront で静的ホスティング。デザインは Tailwind CSS、アイコンは Lucide、ナビゲーション共通化は Web Components。すべて CDN 読み込みで、ビルドツール不要のシンプルな構成だ。
育休中の空き時間で数週間かけて作った。4人の子の世話をしながらなので、連続した開発時間は取れない。でも 「30分あれば1ページ進められる」 のが Claude Code の強みだった。
副産物：自分のキャリアが整理された
サイトを作る過程で、スキルデータや職歴データを JSON で整理した。「PHP を7年使ってきた」という漠然とした認識が、「CakePHP のカスタマイズが可能、設計・実装・レビューが可能」という言語化された情報になった。自分のキャリアを棚卸しするという意味で、意外とこれが一番収穫だったかもしれない。
やってみてわかった3つのこと
Learning 01
「AIへの指示」は「設計の言語化」そのものだ
あいまいな指示はあいまいな結果を生む。「何を作りたいか」「どんなルールを守るか」「何を出力してはいけないか」——これを言語化する力が問われる。
これはエンジニアが日常的にやっている要件定義・仕様書作成とまったく同じスキルだ。つまり、エンジニアほど Claude Code を使いこなしやすいかもしれない。
Learning 02
AI は「補完」ではなく「実装者」として使う方が速い
「コードのアドバイスをもらう」ではなく、「実装を全部任せる」という使い方に切り替えたとき、スピードが一段上がった。
自分がやることは「設計の判断」と「品質の確認」。手を動かす部分はAIに委譲する——この役割分担が決まってから、育休の隙間時間でも十分進められるようになった。
Learning 03
「動くものを見てから考える」が最速だった
デザインの好みは、頭の中では曖昧なままでいい。まず動くものを作ってもらって、見てから「ここが違う」と言う方が圧倒的に速い。
アジャイル開発の「動くソフトウェアを優先する」という考え方は、AI 活用でもそのまま通用した。
まとめと、次にやること
「育休中にポートフォリオを作る」という目標は達成できた。自分の経歴を整理する場として、リベシティの名刺として、どちらの目的にも使える形になった。
このプロジェクトは、ポートフォリオを作った話であると同時に、「AIと協業する実験」の記録でもある。Claude Code という道具の使い方を学びながら、自分のキャリアを整理するという、一石二鳥の体験だった。
エンジニアでなくても、「自分の言葉で設計を伝える能力」があれば、同じことができる時代になってきていると感じた。逆に言えば、「何を作りたいか」を言語化できない人にとっては、AIは道具にならない。
次にやること
- Lab 記事を通じて発信を続ける
- Lab 記事を増やす（例：キャリア×資産の統合分析・AWS構成の改善記録 等）
- Tools セクションのリニューアル（旧ツールの整理）
このサイト自体がポートフォリオです。
About にキャリア・スキル・実績をまとめています。