Posts

自分のサイトのドメインを、お名前.com から Cloudflare Registrar へ移した。作業は全部 Claude Code に伴走させている。移管先の比較も、対象ドメインの状態確認も、手順の提示も AI 側にやらせて、自分は管理画面を操作する係に回った。 やってみて分かったのは、AI を横に置いても停滞は消えないということだった。このタスクは 7 月に一度着手して、2 か月止まっていた。止まっていた原因は、AI が代われない 2 か所に全部あった。ブラウザの管理画面の操作と、bot からアクセスできない公式ヘルプである。以下はその記録になる。 タスクを 2 か月寝かせていた 普段、思いつきレベルのタスクは Obsidian の 1 ファイルに溜めていて、それを読み書きする自作のスラッシュコマンドを Claude Code に登録してある。一覧を出すコマンドを叩くと、未着手のタスクが並ぶ。 その一覧に「fuji-kinoe.net をお名前.com から Cloudflare Registrar へ移管」という行が 2 か月残っていた。今日たまたま一覧を出したら、Claude のほうから「これ、いま開いているプロジェクトのドメインですよね」と指摘された。言われるまで結び付いていなかった。 思いつきの箱とプロジェクトごとの作業キューを分けて運用しているので、こういう取りこぼしが起きる。分けている理由はあるのだが、ドメインのように明確にプロジェクトへ紐づくものは、最初から作業キュー側へ移しておくべきだった。 状態の確認は、AI に任せてちょうどよかった 7 月のメモには「移管可能」と書いてあった。ただ 2 か月経っているので、そのまま信じずに取り直してもらった。 Claude が叩いたのは RDAP という、WHOIS の後継にあたる仕組みである。レジストリがドメインの登録情報を JSON で返してくれる。.net なら Verisign が出している。 https://rdap.verisign.com/net/v1/domain/fuji-kinoe.net 結果は 7 月と同じだった。ステータスが active だけで移管ロックがかかっていないこと、ネームサーバーが既に Cloudflare を指していることが確認できた。後者のおかげで、レジストラを移してもサイトの応答元は変わらないので移管中も止まらない。 この工程は AI に向いている。URL を叩いて JSON を読み、必要な項目を抜き出すだけで、判断の余地が少ない。私が WHOIS の画面を開いて目で追うより早いし、ロックの有無をステータスの配列で機械的に判定してくれるので見落としにくい。 ...

画像だけが、やり取りに乗らなかった 同じWebサイトを Claude Code と Codex の両方で作ってみた。コードを書く力だけを見ていると、この二つの違いは分からない。差が出たのは、ゼロから画面をデザインして、そこで使うキャラクターの絵まで用意する仕事だった。この種の仕事では、絵を作る作業をそのまま続けられる Codex のほうがやりやすかった。 Claude Code でもデザインの相談はできている。Claude Design とは直接つながらなかったので、依頼と返事を文書に書いて渡し合う形にした。手間はかかるが、余白の取り方や情報の詰め方はこのやり取りで決まった。ただ、絵だけはこの形に乗らない。私の環境では Claude Code が絵を作る手段を持たないので、独自のイラストが要ると、デザインを考える作業と絵を用意する作業の間に別の手順が挟まる。 以下は、案内役のキャラクターがいるWebサービスを作り直したときに起きたことと、その結果どう使い分けることにしたかである。 絵を一枚作れば済む話ではなかった トップページ、入力中の画面、結果ページに、それぞれ別のポーズの絵を置いた。最初は、絵さえ用意できればあとは実装だけだと思っていた。 実際にやってみると、そうはならなかった。まず参考にする絵から「線が少ない白黒の線画」というテイストを読み取る。次にヘッダー用、指をさす姿、考える姿を描き分ける。余白と人物の向きを画面に合わせ、置いてみて吹き出しと重なっていないか見る。一枚だけ絵柄がずれていたら作り直す。最後には、キャラクターに合わせて見出しもボタンも受け答えの口調も直すことになった。 絵は一枚納品して終わりではなく、実装と行き来しながら詰めるものだった。人の仕事にたとえるなら、デザイナーとイラストレーターと実装担当の間を自分が歩き回る回数が減った、という感覚に近い。役割が一つになったわけではないが、試作の段階では伝言がかなり減る。 二つを並べると、こうなる 同じサイトでも、要件の整理と名前の付け替えは Claude Code で進めた。絵とデザインの調整は Codex に頼んだ。両方を触った印象を並べる。 観点 Claude Code Codex 画面の構成やデザインの方針 Claude Design と文書をやり取りして決められる コードと会話を往復しながら決められる 独自の絵を作る 私の環境では別の手段が要る 同じ作業の流れの中で作れる 絵と実装の行き来 絵を外から渡す手順が増える 作る、置く、見る、作り直すが続けられる 見た目の確認 実装したあとで確認できる 画面の確認と絵の直しをまとめて頼める 効いたのは、二段目の「独自の絵を作れるかどうか」だけだと思う。画面を組んでいる途中で「ここにもう一つポーズが欲しい」と気づくことがある。そのとき、思いつきをその場で絵に変えられるかどうかで、進み方がずいぶん違った。ほかの三つは、この一点から出てくる差だった。 具体的にどう違ったのかを、三つの場面で書く。 「三枚目だけ絵柄が違わないか」と言ったあと 三枚並べてみたら、最後の一枚だけ他と違って見えた。そう Codex に伝えると、絵を作り直し、コードの参照先を差し替え、ページを開いて確かめるところまで同じ相手が続けてくれた。私は別のツールを開いていないし、ファイルを手で置き換えてもいない。この「言った直後に直る」感じが、今回いちばん印象に残った。 参考にできるのが画面写真しかないときも、写真をそのまま切り抜くのではなく、雰囲気だけを引き継いで描き直す、という判断がしやすかった。理由は同じで、思いついたその場で試せるからだと思う。 絵だけ見ていても分からなかった せりふが人物に重なる。ヘッダーの絵だけ線が細かい。三枚目だけ絵柄が違う。今回出た問題は、どれも絵のファイルを単体で開いていては気づけなかった。うまい絵でも、吹き出しと重なったり、視線が本文と反対を向いていたりすれば、画面としては使いにくい。作った絵をそのまま画面に入れて、開発中のページで見て、駄目なら作り直す。この流れが切れないことが効いた。 名前の読み仮名まで直すことになった キャラクターは見た目だけでは立たない。サイト名、見出し、案内の文、待っている間の文言、返ってくる答えの口調。ここまでそろって、ようやくこの人に案内されている感じが出る。絵を作ったあとに、その人物像へ合わせて言い回しも直せた。 途中で、キャラクターの名字が初めて見ると読みにくいことに気づいた。結局、共通のヘッダーに読み仮名を添えるところまでやった。絵から始まった変更が、文章の側へ広がっていった。 作り直しになったところ 便利だった一方で、絵の生成そのものには手間もかかった。 同じ指示でも、ポーズごとに線の量や顔つきが少しずつ変わる 一枚だけ写実寄りになって、並べたときに浮く 同じファイル名で差し替えると、開発中の画面が古い絵を表示したままになる キャラクターの名前や設定を変えたら、絵だけでなく、指示文や作り置きした回答も直すことになる 絵を作れること自体は、できあがりの品質を保証しない。「この一枚だけ違う」「この言い方はこの人らしくない」と判断して直しを頼む仕事は、こちらに残る。それでも、気づいたその場で作り直しと差し替えに進めるのは大きかった。 次も同じ選び方をするか する、というのが今の答えになる。次に独自の絵が要るサイトをゼロから作るなら、絵まわりはまた Codex に頼む。要件の整理、処理の直し、文章の詰めは Claude Code のほうが話が早いので、そこは変えない。 ...

導入 Claude Code を npm install -g で使っている人、まだ多いのではないだろうか。 先日、Claude Code を最新版に更新しようとしたら「すでに最新版です」と言われた。自分で更新した覚えはない。調べてみると、ネイティブインストールにはバックグラウンド自動更新の仕組みがあり、知らないうちに最新版が適用されていたのだった。 実は npm インストールはすでに非推奨になっている。この記事では、ネイティブインストールと npm インストールの違い、移行方法をまとめる。 ネイティブインストールと npm インストールの違い ネイティブインストール（推奨） npm インストール（非推奨） インストール方法 公式スクリプト npm install -g Node.js 不要 18 以上が必要 自動更新 バックグラウンドで自動 なし（手動で npm update -g） 更新方法 claude update または自動 npm update -g @anthropic-ai/claude-code バイナリ署名 macOS: Apple 公証済み / Windows: 署名済み なし 大きな違いは 自動更新 と Node.js 不要 の 2 点だ。 ネイティブインストールでは起動時と実行中に定期的に更新チェックが走り、新しいバージョンがあればバックグラウンドでダウンロード・インストールされる。次回起動時に自動で適用されるため、常に最新の機能とセキュリティ修正が使える。 また、Node.js が不要になるのも嬉しい。Claude Code のためだけに Node.js をグローバルに入れていた人は、その依存を外せる。 ネイティブインストールの手順 注意: インストール手順は変更される可能性があります。最新の方法については公式ドキュメントを確認してください。 ...

Node.js のバージョン管理に長らく nvm を使ってきたが、volta に乗り換えた。移行はかなりシンプルだったので、手順をまとめておく。 なぜ乗り換えたか nvm は歴史が長く、安定はしているけど、いくつか気になる点があった。 シェルの起動が遅くなる — nvm はシェル起動時に初期化スクリプトを読み込む。シェルを開くたびにわずかなラグが入る シェルごとに設定が必要 — bash と zsh で別々に設定を書く必要がある プロジェクトごとの自動切り替えが面倒 — .nvmrc を置いても nvm use を手動で叩くか、フックを仕込む必要がある volta はこのあたりをうまく解決している。 シェルに依存しない — Rust 製のバイナリで、PATH に追加するだけ 速い — シェル起動時のオーバーヘッドがほぼない プロジェクト単位のバージョン固定 — package.json に volta フィールドを書くだけで、プロジェクトに入ったら自動でバージョンが切り替わる 移行手順 1. volta をインストール curl https://get.volta.sh | bash これだけで ~/.volta/ にインストールされる。インストーラが .profile や .bashrc に PATH を自動追記してくれるが、zsh を使っている場合は自分で設定した方が確実。 2. シェルの設定を更新 .zshrc など、普段使っているシェル設定ファイルで nvm の設定を volta に置き換える。 Before（nvm）: export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" After（volta）: ...

dotfiles とは .zshrc や .vimrc など、ドット（.）で始まる設定ファイル群を dotfiles と呼ぶ。これらを Git で管理しておくと、複数の PC 間で開発環境を統一したり、新しい PC を素早くセットアップしたりできる。 移行前の構成 ~/dotfiles に設定ファイルを置き、install.sh でシンボリックリンク（ショートカットのようなもので、実体ファイルを一箇所で管理しつつ本来の場所から参照させる仕組み）を貼る方式で管理していた。 ~/dotfiles/ ├── .zshrc ├── .zsh/ # env, options, bindings, ohmy ├── .vimrc ├── .vim/ # init.vim, init/ ├── .tmux.conf ├── .tmux/plugins/ # TPM (git submodule) ├── install.sh # ln -sf でリンクを貼るスクリプト └── README.md install.sh の中身はシンボリックリンク作成 + oh-my-zsh / TPM のインストール。 なぜ chezmoi（シェイ・モワ）に移行したか 独自スクリプト方式には以下の課題があった。 ファイル追加のたびに install.sh を手動更新する必要がある — 管理対象が増えるほど面倒 テンプレート機能がない — PC ごとにトークンやホスト固有設定を変えたい場合、自分で分岐を書く必要がある シンボリックリンク方式の制限 — WSL から Windows 側パスにはリンクが貼れないなど、環境をまたぐと問題が出る chezmoi はこれらを解決する。 ...

概要 Obsidian を使いはじめたころから「グラフビューを活かしたい」と思っていたのですが、内部リンクやタグ付けがどうしても面倒で、つい放置してしまっていました。 テンプレート機能でノート作成時に日付タグを付ける程度の運用はしていたものの、グラフビューを見る限りあまり効果は感じられませんでした。 そんな中で、「生成AIを使えば自動化できるのでは？」と思い立ち、AIに方法を尋ねてみたところ、メモ内容から自動で内部リンクを生成し、ノート整理や検索を効率化できる手順が見つかりました。 今回はその方法を紹介します。 使用ツールは以下の通りです。 Obsidian Text Generator プラグイン OpenAI API 手順概要 1. Obsidian の準備 Obsidian をインストール https://obsidian.md/ からダウンロードします。 使用する Vault（メモ保管フォルダ）を開きます。 2. Text Generator プラグインの導入 設定 → 「Community plugins」 → 「Browse」 検索バーに「Text Generator」と入力 「Install」 → 「Enable」をクリック 3. OpenAI API キーの取得 https://platform.openai.com/api-keys にアクセス 「+ Create new secret key」から新しい API キーを発行 表示されたキーをコピー（後で Text Generator に設定） ※ OpenAI API を利用するには従量課金の設定が必要です。詳細は公式サイトをご確認ください。 4. Text Generator の API 設定 Obsidian → 設定 → 「Text Generator」 Provider Profile を「OpenAI Chat」に設定 API Key に先ほど取得したキーを貼り付け Model name は gpt-4.1-nano または gpt-4.1-mini を推奨（高速・低コスト） Text Generator Options で insert-text-From-template を有効化 5. テンプレートファイルの作成 Vault 内に templates/ フォルダを作成 generate-links.md を作成し、以下を記述： あなたは Obsidian のノートアシスタントです。 以下のノートの内容やメタ情報を読み取り、関連しそうな概念やトピックを 3〜5 個提案してください。 これらは「タグ」ではなく、すべて Obsidian の内部リンク（`[[...]]`）として出力してください。 - 各リンクは 1 語または短いフレーズ（例：[[AI]], [[生成AI]], [[OpenAI]], [[Obsidian]] など） - 既存ノートに存在していなくても構いません。 - 出力フォーマットは以下の通り： 出力フォーマット: [[link1]] [[link2]] [[link3]] 本文： {{content}} --- 生成理由や説明文は不要です。出力は上記フォーマットのみでお願いします。 6. Text Generator のテンプレート登録 Obsidian → 設定 → 「Text Generator」 → 「Advanced Settings」 「Templates Path」に templates を指定 コマンド「Text Generator: Templates: Insert Template」から呼び出せるようにします 7. 実行例 Obsidian でノートを作成 「Ctrl + P」でコマンドパレットを開く 「text generator」と入力して「Text Generator: Templates: Insert Template」を選択 generate-links.md テンプレートを選択 実行すると、カーソル位置に内部リンクが自動挿入されます 補足 他の LLM を利用したい場合は、Text Generator の「LLM Settings」で切り替え可能です。 無料で構築したい場合は、ローカルモデルの ollama なども利用できます。 最終構成例 Vault/ ├─ templates/ │ └─ generate-links.md ├─ notes/ │ ├─ sample.md │ └─ ... └─ .obsidian/ └─ plugins/ └─ obsidian-textgenerator-plugin/ まとめ この構成により、ノート内容から自動で関連タグや内部リンクを生成できるようになります。 整理や検索が効率化し、知識ベースとしての Obsidian 活用がさらに強化されます。

最初の投稿です！