2025-07-02

Claude Code の Plan Mode 活用ガイド

TL;DR

Claude CodeのPlan Modeは、実装前に計画を共有する仕組み。品質保証としても、アイデアを形にする対話ツールとしても使えます。4ステップ（STOP→DISCUSS→WAIT→IMPLEMENT）で、手戻りゼロ＆より良い実装を実現。

背景：なぜPlan Modeが生まれたか

AIツールがコードを書く際の最大の問題は「勝手に間違った方向に実装を進めてしまう」こと。その結果、次のような問題が発生します。 - 意図しない実装で時間を無駄にする - 修正に追加の時間がかかる - 最悪の場合、全部書き直し

Plan Modeとは

Claude Codeの実装前対話システム。コードを書く前に計画を提示し、ユーザーと対話しながら最適な実装方法を見つける機能です。単なる承認システムではなく、アイデアを具体化する協働ツールとして機能します。 Claude Codeを起動した後、Shift + Tabを2回押すことでPlan Modeにできます。

公式ドキュメントにはPlan Modeの説明がなかったです。claudeを起動したときの Tip は注視すべしということでしょうか...

こんな人におすすめ

手戻りを防ぎたい（防御的価値）
曖昧なアイデアを具体的な実装に落とし込みたい（創造的価値）
AIの技術知識を活用して複数の選択肢を検討したい（対話的価値）

実際の効果

Plan Mode導入前後の違い。

Before（Plan Modeなし）

User: 「ユーザー認証機能を追加して」
AI: 「実装しました！」→ 全然違うライブラリを使用
結果: 3時間かけて書き直し

After（Plan Modeあり）

User: 「ユーザー認証機能を追加して」
AI: 「計画：既存のAuth0を使用、3ファイル変更」
User: 「いや、Firebaseで」
AI: 「了解です」→ 正しい実装
結果: 手戻りゼロ

具体的な使い方

CLAUDE.mdに以下のルールを追加する (お守り程度と考えてください、2~4を確実にやる方が重要です)
Shift + Tabを2回叩いてClaude CodeをPlan Modeにする
やりたいことを提示して、Claude Codeに探索させる
例 APIにOAuth2を使用した新しい認証システムを実装する必要があります。コードベースでこれを実装する最良のアプローチについて深く考えて
提案された内容を見て1つずつフォローアップする
例 このアプローチの潜在的なセキュリティ脆弱性について考えて

docs.anthropic.com

拡張思考のヒント - Anthropic

Plan Modeルール

## Task Workflow Rules

### IMPORTANT: Task Implementation Process

When starting any task that is NOT in "planned" status (i.e., todo, backlog, pending):
1. **STOP** - Do not write any code
2. **DISCUSS** - Present a detailed implementation plan to the user
3. **WAIT** - Get user approval on the plan
4. **IMPLEMENT** - Only after approval, proceed with implementation

### Implementation Plan Should Include:
- Current situation analysis
- Proposed solution approach
- API design / interface changes
- File structure changes
- Testing strategy
- Potential risks or considerations

### DO NOT:
- Skip the planning phase
- Make assumptions about implementation details
- Write code before getting user approval
- Ignore design principles while implementing

This workflow ensures quality and prevents wasted effort on wrong implementations.

このルールにより、タスク開始前に必ず計画を提示し、承認を得てから実装する流れが確立されます。

Plan Modeが威力を発揮するシーン

新機能の実装 → 使うライブラリや設計を事前確認
リファクタリング → 影響範囲を明確化してから着手
バグ修正 → 修正方針を確認してから実装

Plan Modeの真価

基本：品質保証として

Plan Modeは手戻りを防ぎ、品質を保証する重要な仕組みです。これだけでも十分価値がありますが..。

発展：対話ツールとして

より大きな価値は「実現に向けた対話のパートナー」として使うことです。たとえば、次のような使い方があります。

曖昧なアイデアを具体的な実装計画に落とし込む
複数の技術的選択肢を比較検討する
AIの技術知識とあなたのビジネス知識を組み合わせる
「こんな方法もありますが」という新しい視点を得る

まとめ

Plan Modeは「AIに丸投げ」から「AIと協働」への転換点。防御的な品質保証として始まり、創造的な対話ツールとして花開く。実装前の数分の対話が、より良い解決策への道を開きます。

2025-06-06

Alacrittyにフォントを設定する方法とHackGenについて

Note

この記事はAIで生成しました。人間が実際に動くことを確認しています

ターミナルエミュレータのAlacrittyでフォントを設定する方法と、日本語プログラミングに最適なHackGenフォントについて解説します。

Alacrittyのフォント設定方法

Alacrittyでは設定ファイルを編集してフォントを指定します。設定ファイルの場所は~/.config/alacritty/alacritty.ymlまたは~/.config/alacritty/alacritty.tomlです。

YAML形式での設定例

font:
  normal:
    family: "フォント名"
    style: Regular
  bold:
    family: "フォント名"
    style: Bold
  italic:
    family: "フォント名"
    style: Italic

TOML形式での設定例

[font.normal]
family = "フォント名"
style = "Regular"

[font.bold]
family = "フォント名"
style = "Bold"

[font.italic]
family = "フォント名"
style = "Italic"

HackGenフォントとは

HackGenは日本語プログラミングに特化したフォントです。以下の特徴があります：

日本語とプログラミング用途の両方に最適化
全角文字と半角文字のバランスが絶妙
Console版では全角スペースが可視化される
Nerd Font対応版でアイコンも表示可能

HackGenのインストール方法（macOS）

Homebrewを使用して簡単にインストールできます：

brew install --cask font-hackgen

HackGenのバリエーション

フォント名	特徴
HackGen	標準版
HackGen35	35%幅の日本語文字版（コンパクト）
HackGen Console	全角スペース可視化版
HackGen35 Console	35%幅 + 全角スペース可視化版
HackGen Console NF	Console版 + Nerd Font（アイコン対応）
HackGen35 Console NF	35%幅 + Console版 + Nerd Font

フォントの確認方法

インストールしたフォントが利用可能か確認：

# HackGenフォントの確認
fc-list | grep -i hackgen

# より詳細に確認
fc-list : family | grep -i hackgen

Alacritty + HackGenの設定例

標準的な設定（HackGen）

font:
  normal:
    family: "HackGen"
    style: Regular
  bold:
    family: "HackGen"
    style: Bold
  size: 12.0

Nerd Font対応版

font:
  normal:
    family: "HackGen Console NF"
    style: Regular
  bold:
    family: "HackGen Console NF"
    style: Bold
  size: 12.0

コンパクト版（35%幅）

font:
  normal:
    family: "HackGen35 Console NF"
    style: Regular
  bold:
    family: "HackGen35 Console NF"
    style: Bold
  size: 12.0

選んだフォント設定

私は最終的にHackGen Console NFを選択しました。

font:
  normal:
    family: "HackGen Console NF"
    style: Regular
  bold:
    family: "HackGen Console NF"
    style: Bold
  size: 12.0

設定の反映

フォント設定を変更した後は、Alacrittyを再起動して変更を反映させてください。

pkill alacritty && open -a Alacritty

まとめ

AlacrittyでHackGenフォントを使用することで、日本語を含むプログラミング作業の可読性が大幅に向上します。特にHackGen Console NF版は、全角スペースの可視化とNerd Fontのアイコン表示により、実用性の高い開発環境を構築できます。

参考リンク

2025-06-06

はてなブログでGitHub風アラートを実装する方法

GitHubのMarkdownで使える便利なアラート機能を、はてなブログでも使えるようにする方法を紹介します。

完成イメージ

以下のようなGitHub風のアラートボックスを実装できます

やり方

ステップ1: デザインCSSの設定

「デザイン」→「カスタマイズ」→「デザインCSS」に以下gistのcssを追加

gist.github.com

ステップ2: 記事での使用方法

記事編集画面で、以下のようにアラートを記述。テンプレートをsnippetにしておくと便利です。

<!-- Note Alert -->
<div class="markdown-alert markdown-alert-note">
  <p class="markdown-alert-title">Note</p>
  <p>重要な情報や参考になる内容を記載します。読者がスキミングしていても見落とさないような情報です。</p>
</div>

<!-- Tip Alert -->
<div class="markdown-alert markdown-alert-tip">
  <p class="markdown-alert-title">Tip</p>
  <p>便利なヒントや、より良い方法を提案する際に使用します。</p>
</div>

<!-- Important Alert -->
<div class="markdown-alert markdown-alert-important">
  <p class="markdown-alert-title">Important</p>
  <p>ユーザーが目標を達成するために絶対に知っておくべき重要な情報です。</p>
</div>

<!-- Warning Alert -->
<div class="markdown-alert markdown-alert-warning">
  <p class="markdown-alert-title">Warning</p>
  <p>問題を回避するために、ユーザーが immediate attention を払うべき重要な内容です。</p>
</div>

<!-- Caution Alert -->
<div class="markdown-alert markdown-alert-caution">
  <p class="markdown-alert-title">Caution</p>
  <p>特定の行動による negative outcomes やリスクについて警告する際に使用します。</p>
</div>

使用可能なアラートタイプ

タイプ	用途	色
Note	一般的な情報、補足説明	青
Tip	便利なヒント、コツ	緑
Important	重要な情報	紫
Warning	警告、注意喚起	オレンジ
Caution	リスクや危険性の警告	赤

まとめ

これで、はてなブログでGitHubと同じ見た目のアラートが使用できるようになります。技術記事やドキュメント作成時に、重要な情報を視覚的に強調できて非常に便利です。

ぜひ試してみてください！

参考リンク

2025-05-24

LIFF InspectorとCloudflare Tunnelを使ってLIFFアプリのローカルデバッグを楽にする

開発環境・ツールフロントエンド開発 LINE開発

TL;DR ― これだけ叩けば OK

# 1️⃣ cloudflared インストール
brew install cloudflared   # macOS の例

# 2️⃣ LIFF Inspector 起動（ローカル :9222）
npx @line/liff-inspector    # 初回のみ npx が便利

# 3️⃣ Quick Tunnel 作成（LIFF Inspector 用）
cloudflared tunnel --url http://localhost:9222 --no-chunked-encoding

# 4️⃣ LIFF アプリ (Next.js など) 起動（ローカル :3000 の例）
npm run dev -- --port 3000

# 5️⃣ Quick Tunnel 作成（LIFF アプリ用）
cloudflared tunnel --url http://localhost:3000 --no-chunked-encoding

# 6️⃣ LINE Developers でエンドポイント URL を設定
#   https://{LIFFアプリURL}?li.origin=wss://{InspectorURL}:9222
#   ↑ { } はさっき表示された trycloudflare.com ドメインで置換

うまく繋がらないときは Quick Tunnel を短時間で何度も貼り直していないか疑ってください。5 分くらい待ってから再実行すると通るケースが多かったです。

TL;DR ― これだけ叩けば OK
0. ネットワーク構成イメージ
1. はじめに
2. 必要なツール
3. LIFF Inspector を立ち上げる
4. Cloudflared Quick Tunnel で外に出す
- 4-1. Inspector 用トンネル
- 4-2. LIFF アプリ用トンネル
5. LINE Developers でエンドポイントを設定
6. スマホで確認 & DevTools 接続
7. 補足 & トラブルシューティング
8. まとめ
ちなみに

0. ネットワーク構成イメージ

下図は スマホの LINE アプリ → Cloudflare（Quick Tunnel）→ ローカルの LIFF アプリ / LIFF Inspector という流れをざっくり可視化したものです。HTTPS と WSS の経路が分かれば後の手順もイメージしやすいと思います。

1. はじめに

LINE Mini App（LIFF）をローカルでデバッグするときにネックになるのが “HTTPS” と "LIFF ブラウザ " の問題。そこで Cloudflare Tunnel（cloudflared）の Quick Tunnel 機能と公式の LIFF Inspector を組み合わせると、数コマンドで外部公開 & デバッグが可能になります。

ただし WebSocket (ws://) を Cloudflare が通してくれない という罠があるので、Inspector 側を https:// → wss:// へ書き換えて回避するのが今回のキモです。¹

2. 必要なツール

ツール	バージョンの目安	インストール
cloudflared	最新版推奨	`brew install cloudflared`（mac）
@line/liff-inspector	^1.0.0	`npm i -D @line/liff-inspector`
Node.js / npm	v18 以降	お好みの方法で

3. LIFF Inspector を立ち上げる

npx @line/liff-inspector

起動ログに ws://localhost:9222 が出ますが、LIFF からは HTTPS/WSS でないと混在コンテンツ制限で弾かれます。そこで “HTTP に変換 → トンネル → WAN 側で HTTPS → WSS に書き戻し” という三段活用が必要です。

4. Cloudflared Quick Tunnel で外に出す

4-1. Inspector 用トンネル

cloudflared tunnel --url http://localhost:9222

出力に https://something.trycloudflare.com が表示されたらメモ。

Cloudflare Tunnel は WebSocket をサポートしておらず、HTTP 経由でラップする必要があります。色々探しても明確なものが無かった^2、でもログはそう言ってる

ERR Couldn't start tunnel error="Error validating origin URL: Currently Cloudflare Tunnel does not support ws protocol."

4-2. LIFF アプリ用トンネル

アプリを localhost:3000 で動かした状態で:

cloudflared tunnel --url http://localhost:3000

こちらも https://...trycloudflare.com がもらえるのでメモ。

Quick Tunnel は短時間で貼り直すと「サーバーが見つかりませんでした」が出がちです。焦らず数分待ちましょう。 MacBook では頻繁に発生しているが、Windows だと発生しない

5. LINE Developers でエンドポイントを設定

チャネルの「基本設定」→「エンドポイント URL」へ。
以下の形で入力して保存。

https://{LIFFアプリURL}?li.origin=wss://{InspectorURL}:9222

{LIFFアプリURL} = 手順 4-2 で得た https://xxxx.trycloudflare.com
{InspectorURL} = 手順 4-1 の URL を https:// → wss:// に置換

li.origin パラメータは URL エンコード必須 なケースもあるので、繋がらなければ一度変換してみてください。

LIFF CLI で LINE Developer Console 開かなくても書き換えできる可能性大 (試してない)

6. スマホで確認 & DevTools 接続

スマホ LINE からミニアプリ起動 → Inspector 起動ターミナルに DevTools URL: devtools://... が出現
その URL を PC の Chrome アドレスバーに突っ込むと、通常の DevTools が開いてデバッグ OK。

7. 補足 & トラブルシューティング

症状	よくある原因	処方箋
`Server Not Found`	Tunnel を数秒で貼り直した / サブドメイン発行が遅延	5 分ほど待って再実行
Inspector だけ繋がらない	`wss://` 変換漏れ	URL 書式を再確認

代替手段 Cloudflared が合わない場合は、ngrok で同等のトンネルを張るのもアリです（説明は割愛）。

8. まとめ

LIFF Inspector × Cloudflared で、スマホ実機からローカル環境を HTTPS/WSS 付きで簡単公開。
Quick Tunnel は貼り直しすぎるとエラーになるから注意。
WebSocket でコケるので http でトンネルを掘る。

これでローカルでも快適に LIFF アプリをデバッグできます。やったね！

ちなみに

LIFF Mock 編があるかも？

wss or ws connections won't work on a http or https tunnel🐛 · Issue #1164 · cloudflare/cloudflared ↩

2024-08-17

【イベント】自分が苦しまないためのソフトウェア開発 by たくてぃんさんでWhy/What/Howがつながった

イベントの概要
三ノ宮と区役所文化センター
Coding Skill
DIと宣言的なコード
つまり、、、？
感想
ありがとうございました！
追記

イベントの概要

ソフトウェア開発で自分が苦しまないためのアーキテクチャや設計の考え方ややり方をたくてぃんさん @taku_ting に教えてもらうイベント

kobe-sannomiya-dev.connpass.com

三ノ宮と区役所文化センター

初めて神戸三宮に訪れた！

会場は中央区の区役所文化センター

Coding Skill

ソフトウェアによる価値の提供を拡大・継続できるようなコードが書けているか？
Coding Skill = スケーラビリティとサステナビリティを実現するコードを書く力のこと
速度・効率、保守性を向上するにはコンピュータ（どうやってコードが動いているか）を理解する必要がある
スタンダードな探索アルゴリズムとソートアルゴリズムを自分で書けるくらいの知識は必要
サステナビリティ = メンテナビリティ + テスタビリティ
技術負債を最小にして、最速で実装・対応できるかを自問自答して、コンピュータの理解とアルゴリズム・デザインパターン / アーキテクチャの理解を高める
大事なコードを、そうでないコードに依存させてしまうと大事なコードを守れなくなる
そこで依存を逆転させて、そうでないコードを大事なコード側にあるInterfaceに依存させる
技術選定の視点は「作れるか」ではなく、「継続的なメンテナンスに過不足なく耐えられるか」を基準に意思決定する
- 技術選定の対象はソフトウェアアーキテクチャとフレームワーク、インフラアーキテクチャ、インフラなどなど
Coding Skillを向上するにはコンピュータの理解をして、次の引き出しを増やす
- アルゴリズム
- デザインパターン
- ソフトウェアアーキテクチャ
ソフトウェア開発には、二つのフェーズがある
- 検証フェーズ → 拡大フェーズ
- 検証フェーズでは、ビジネスとして上手くいくかを確認するのが目的なのでフレームワークやアーキテクチャには拘らずにとりあえずつくる
  - ただ、検証フェーズから最適なフレームワークやアーキテクチャを考えておく
レイヤーの増減については、ビジネス上の制約(下記後述)によって考えている
- アクセス制御
- キャッシュ制御
- ストレージ制御

DIと宣言的なコード

コードレビューは何のためにやるか
- チーム・プロダクトの文化に馴染むため
- コードが正しく動くか、表現されているかをチェックする
チームメンバーの文化や背景を理解してコードレビューする
可読性は、読みにくい・読みやすいではなく具体的にどういった理由で読みにくいのかの観点でレビューする
チームで喧嘩しないように絶対言語ごとのコード標準を使ったフォーマッターを入れる
- 人の意見よりシステム（組織・コミュニティ）からの意見の方が受け入れられる
関数は処理の「切り分け」や「共通化」をするため
- 切り分け = プログラムの責務の分離
- 共通化 = 共通部分の再利用
- ポリモーフィズムは共通化と切り分けを同時にあわらせられているように見えて共通化に寄っているので注意して使う
依存性の注入（DI）だけでなくメソッドインジェクションをつかうことで、責務を分離したコードを書けるようになる
Array.forEachやArray.mapなどの高階関数は処理を宣言的にするために使っている
命名するときはSVOを意識している
宣言的な書き方をすることで、テストを並列で実行できるようになる

つまり、、、？

テストコードを極めることで、Coding Skillが向上する！

大事なコードをテストする、テストを並列で実行できるようにする。
これらができるコードを書くことを意識すれば、おのずとプロダクションコードとしても質が上がる

感想

イベント参加して良かった！オフラインイベント楽しい！！

知識や概念は知っていても実際にやるにはどうしたら良いんだ。。。？ってなってたところをライブコーディングで補ってくれて知るだけじゃなく理解が出来たって言う感覚を覚えたなー

ありがとうございました！

イベント開催していただいた三宮.devのてさおさん @tettyanman と、講師やっていただいたHACKBARのたくてぃんさん @taku_ting に感謝です 🙏

sannomiya.dev

hackbar.jp

追記

たくてぃんさんがイベントの途中に頭疲れるだろうからって5袋ラムネ買って配ってくれていた、気配りすごすぎ。。。ありがとうございます！
余りもって帰っていただいてる😋

2024-08-16

2024/08 自分の強みにする領域

必須で鍛え続ける能力

課題定義
仮説思考
業務分析・ドメインモデリング
ソフトウェアアーキテクチャ設計

強みにする/やりたい領域（NOVASTOの中での話）

システム運用・保守対応（運用改善）
- ちょっとやって一番ワクワクしたから
データ分析
- リリースした機能の利用状況を定量的に計測できるようになったら、次のアクションをスムーズに判断できるようになってよりユーザーに提供できる価値が上がるから
- 自分がつくった機能が使われてるかどうか知りたい！知って嬉しくなりたい！
インフラ（AWS・CI/CD）
- やれる人が上の人以外いてなくて出来るようになったら価値が高くなるから
フロントエンド・UI/UX
- 得意な人少なくて、組織の中で価値を発揮しやすいから
バックエンド

2024-08-01

👁️自分を知る

つらつらと...

自分が人生を楽しんでいるとき

自分が生み出した成果を褒められた時
試行錯誤して少しずつ前進できる時
何かに没頭している時
想いを込めてプロダクト開発をしている時

今までの人生で最も楽しかった瞬間は、高校生のゲームに没頭している時。次点で今、想いを込めてプロダクト開発をしている時。

自分がつらくかんじるとき

出口が無いような事に取り組んでいるとき
身近な人を悲しませるような行動をしてしまったとき

今までの人生で最も後悔している事は、親に苦労をかけた事で身近な人を悲しませるような行動をした事。

自分が幸福に感じるときとストレスを感じること

自分は夢中になれる何かに没頭している時が一番幸福と感じる事で、自分が恩義を感じる人の期待を裏切ることは一番ストレスになるということ

自分の考えや行動の基準

💡 『いつまでも技術を楽しんでいたい』

これが、自分の考えや行動の基準
その為の手段としてエンジニアリングを通じたものづくりをしており、今後も人としても、エンジニアとしての腕前も磨いていきたい。

⛔ 逆に、周りの人や若い人から煙たがられるような人にはなりたく無い。

そのために

自分が知らない事を減らしていきたいしどんな場面でも冷静に対処できるようになりたい。そして、相手のことを考えた行動や発言ができるようになりたい。

いつまでも技術を楽しむために

計画なんて大層なものは必要ない。誰が見ているわけでもステークホルダーが居てるわけでもなし自分だけの自分自身のための活動だからやりたい事はメモして忘れないようにするしいつ頃にはどういったことに手を付けていたいかも考えるし、どういったものを作りたいかも考えていく！

でも、それは絶対にやらないといけないわけではなくあくまでも自分が技術を楽しむためにそういった事をしているだけ

興味とやりたいこと

興味のある技術分野は特にない
直近でやりたいことは、自作DBや自作OS、Linuxの思想の理解
将来やってみたいことは、typescriptやブラウザエンジンなどのOSSのコントリビューター

得意なこと・苦手なこと

得意なこと

苦手なこと

自分の能力に対する見解

自分が得意なこと(模倣と最適化)はスキルとしての伸び代がなくAIにも代替されるような事なので、苦手な部分(情報の構造化と0→1)を得意なことに転じさせたいです

以上！