もしかしてだけど、あれって日本最古のアスキーアートだったんじゃないの？

2026-02-21T00:00:00+00:00

はじめに</h2>
左の画像はMidjourneyで生成したものです
1986年、パソコン通信は黎明期でASCIInetがまだ実験運用の時代でした。その頃の私はグラフィック（おそらくモノクロの有名歌手の画像）を自作プログラムでASCII文字の絵にして、あるパソコン通信のBBS（電子掲示板）に投稿しました。
あれから約40年。当時のアルゴリズムをGoで再実装し、CLIツール `img2char</code> として公開しました。 </iframe>`
`この記事では、当時の背景と img2char</code> のアルゴリズムを紹介します。`

`1986年のパソコンとBBS</h2>`1986年はPC-VAN（1986年4月実験開始）やNIFTY-Serve（1987年4月開始）が立ち上がり始めた、日本のパソコン通信黎明期です。アスキーネット（ASCII-NET）は前年の1985年5月に実験サービスを開始しており、草の根BBSも各地で産声を上げていました。通信速度は300bpsから1200bps。BBSに書き込めるのはテキストだけの時代でした。グラフィックスを書き込むなんてとんでもない時代でした1</a>。 当時のパソコンのグラフィック事情も触れておきます。1986年時点では、画像をファイルとして保存・交換する汎用フォーマットはまだ普及していませんでした。グラフィックを描くといえば、BASICのLINE文やPAINT文を使ってプログラムとして記述するのが主流です。私自身、PAINT文を使わずに画像の上端から下端まで（縦200ドットしかない画面です）をLINE文だけで1ラインずつ塗りつぶし、モノクロ画像を描くことに当時凝っていました。グラフィックは「描く」ものであって「ファイルで送る」ものではなかったのです。 しかもBASICは機種ごとに方言が異なり、あるマシンで書いたプログラムが別のマシンでそのまま動くことはまずありません。グラフィック描画プログラムをBBSで流通させるのも現実的ではありませんでした。 そこで思いついたのが、「ASCII文字絵にすれば遅いパソコン通信でも送れるんじゃね？」です。 Sharp X1 ── 骨の髄までハードを極めたマシン</h2> Sharp X1は1982年に発売された8ビットパソコンです。テレビ事業で培ったシャープの技術が随所に活かされた、ハードウェア設計の塊のようなマシンでした。 当時のZ80 CPUはメモリ空間が64KBしかなく、NECのPC-8801などではこの空間にメインRAMとグラフィックVRAM（GVRAM）を重ねて配置し、バンク切り替えでアクセスしていました。一方X1は、Z80のI/O命令が実行時にアドレスバスの上位8ビット（A8〜A15）にもレジスタの値を出力するという、公式マニュアルには記載されているものの目立たない仕様を活用しました。I/O空間を実質64KBに広げ、そこにGVRAMを配置したのです。メモリ空間64KBは丸ごとRAMとして使え、GVRAMへはI/O命令で直接アクセスできます。 この設計のおかげで、BASICからでもグラフィックVRAM上の画像データを読み出すことができました。グラフィックVRAM上の画像を8x8ドット単位で読み取り、キャラクタROMの各文字パターンと比較する。一致度が最も高い文字を選ぶ。このアルゴリズムをBASICで実装しました2</a>。 アルゴリズムの現代版 ── img2char</h2> img2char</code> は、あの当時のアルゴリズムをGoで忠実に再現したCLIツールです。処理は3段階で構成されています。 フォントパターンの準備 ── 95個のASCII印字可能文字の8x8ビットマップを用意する</li> 画像のブロック分割 ── 入力画像を8x8ピクセルのブロックに分割する</li> パターンマッチング ── 各ブロックとフォントパターンのハミング距離を計算し、最も近い文字を選ぶ</li> </ol> フォントテーブルの構築</h3> 95個の印字可能ASCII文字（スペース 0x20</code> からチルダ 0x7E</code> まで）について、それぞれ8x8ドットのビットマップパターンを持っています。 // font8x8Basic contains 8x8 bitmap patterns for 95 printable ASCII characters (0x20–0x7E). var font8x8Basic = [95][8]byte{ // 0x20 ' ' {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, // 0x21 '!' {0x18, 0x3C, 0x3C, 0x18, 0x18, 0x00, 0x18, 0x00}, // 0x22 '"' {0x36, 0x36, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, // ... 95文字分のパターンが続く // 0x41 'A' {0x0C, 0x1E, 0x33, 0x33, 0x3F, 0x33, 0x33, 0x00}, // 0x7E '~' {0x6E, 0x3B, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, }</code></pre> 各バイトが8x8ビットマップの1行に対応し、LSB（最下位ビット）が左端のピクセルです。たとえば A</code> のパターンを展開すると、以下のようになります。 (2進数はLSB=左端ピクセルから表記) 0x0C = 00110000 → ..##.... 0x1E = 01111000 → .####... 0x33 = 11001100 → ##..##.. 0x33 = 11001100 → ##..##.. 0x3F = 11111100 → ######.. 0x33 = 11001100 → ##..##.. 0x33 = 11001100 → ##..##.. 0x00 = 00000000 → ........</code></pre> 8バイトで1文字の形が表現されています。高速な比較のため uint64</code> にパックします。 func packFont(pattern [8]byte) uint64 { var v uint64 for i := 0; i < 8; i++ { v |= uint64(pattern[i]) << (i * 8) } return v }</code></pre> X1に搭載されていたHu-BASICの整数型は16ビット（2バイト）なので、当時は8バイトのパターンを2バイトずつ4回のXORループで比較していました。現代のGoでは8バイトを1つの64ビット整数に詰め込むことで、後述のXOR演算が一発で実行できます。 8x8ブロックとフォントパターンの照合</h3> ここが核心部分です。画像から切り出した8x8ブロックを、95文字すべてのフォントパターンと比較し、最も「形が近い」文字を見つけます。 func matchChar(block [8]byte, fontTable [95]uint64) byte { blockVal := packBlock(block) bestDist := 65 // max possible is 64 bestIdx := 0 for i := 0; i < 95; i++ { dist := bits.OnesCount64(blockVal ^ fontTable[i]) if dist < bestDist { bestDist = dist bestIdx = i } } return byte(0x20 + bestIdx) }</code></pre> blockVal ^ fontTable[i]</code> のXOR演算で、ブロックとフォントパターンのビットが異なる位置を検出します。bits.OnesCount64</code> でその異なるビット数（ハミング距離）を数えます。64ビット中の不一致ビット数が最小の文字を選ぶ、シンプルかつ強力な方式です。 使い方</h3> 入力画像は640x200または320x200ピクセルの二値化済みPNGである必要があります。前処理用のシェルスクリプトが付属しています。 # 前処理（ImageMagickでリサイズ＋二値化） ./convert.sh input.jpg 640 200 # ASCII文字に変換 img2char input_640x200.png</code></pre> 640x200の画像は80x25文字、320x200なら40x25文字に変換されます。当時は320x200モードの40x25文字でやっていました。 今回、同じロジックで似たような画像を変換してみましたが、なかなかいけています（冒頭の画像を参照）。 もしかして......日本最古のASCII Artなんじゃないの？</h2> 当時の変換結果をパソコン通信のBBSに投稿したところ、ちょっとした話題になりました。テキストしか表示できない端末に、文字だけで画像が浮かび上がるのですから、当時としては驚きだったようです。40x25文字分の解像度しかありませんが、元の画像の輪郭や特徴が文字の組み合わせで再現される様子は、見た人を楽しませるものでした。 ここで少し大胆なことを言わせてください。 文字で画像を表現する試み自体は古く、1898年のタイプライターアートにまで遡ります。コンピューターによる自動変換も、1967年にベル研究所のケネス・ノウルトンがIBM 7094で実現しています。ただしそれは巨大なメインフレームでの話です。 日本に目を向けると、記録に残る最古の「アスキーアート」は1986年6月20日にアスキーネット上で若林泰志が投稿した顔文字 (^_^)</code> とされています。2ちゃんねるでAAが花開くのは1999年以降。1986年当時、手作業でAA（アスキーアート）を描く文化はまだ広まっていませんでした。 そんな時代に、8ビットパソコンで画像をASCII文字に変換してBBSに投稿していたわけです。 もしかして、もしかしてだけど、これって日本最古のアスキーアートなんじゃないの？（どぶろっく風） ......まあ、証拠は当時のBBSのログとともに電子の海に消えてしまいましたが。 まとめ</h2> img2char</code> は、1986年のSharp X1で生まれたアイデアを現代のGoで再実装したツールです。 当時のパソコン通信の制約（テキストのみ）が生んだ発想</li> PCGという強力なハードウェアをあえて使わず、ASCII文字だけで勝負した選択</li> 8x8ドットブロックとフォントパターンのハミング距離による照合という、シンプルだが効果的なアルゴリズム</li> </ul> 40年前のBASICプログラムが64ビット整数のXOR演算に姿を変えても、やっていることは同じです。画像の形を文字の形で近似する。それだけのことが、なぜか人を惹きつけます。 興味を持っていただけたら、ぜひ試してみてください。 </iframe> 参考</h2> アスキーアート - Wikipedia</a> -- 日本におけるアスキーアートの歴史、顔文字の起源</li> ASCII art - Wikipedia (English)</a> -- タイプライターアート（1898年）からの世界的な歴史</li> The history of ASCII Art - ASCII Art Archive</a> -- ベル研のノウルトン（1967年）による自動変換の歴史</li> X1 (コンピュータ) - Wikipedia</a> -- Sharp X1のハードウェア仕様</li> Z80の16ビットI/Oアドレスについての考察（大石氏）-- Z80のI/O命令が16ビットアドレスを出力する仕様の解説（サイト閉鎖）</li> パーソナルなコンピュータのメモリ事情（第3回：8ビット中期）- Electrelic</a> -- X1とPC-8801のGVRAM配置方式の比較</li> パソコン通信の歴史 - 木暮仁</a> -- PC-VAN、NIFTY-Serve、草の根BBSの歴史</li> </ul> そもそも画像をファイルに書き出すフォーマットさえ標準的なものはなかった。 ↩</a> </li> X1にはPCG（Programmable Character Generator）が搭載されており、文字のフォントパターンを自由に書き換えられました。任意のドットパターンを「文字」として表示でき、グラフィックスに近い表現が可能でした。しかしBBSに投稿するならPCGは使えません。相手の画面にPCGのデータは存在せず、表示できるのは標準のASCII文字だけだからです。 ↩</a> </li> </ol> </section>

多機能Todoに疲れた人へ ─「一枚の紙」だけのタスク管理CLI

2026-01-23T00:00:00+00:00

Table of Contents</summary> </details>

はじめに</h2>
ターミナルで作業中、ふと「あれもやらなきゃ」と思いついたとき、頭の中を書き出す場所が欲しくなります。物理的なメモ用紙ならすぐに書けますが、ターミナルから手を離すのは煩わしい。かといって多機能なTodoアプリを開くと、プロジェクトやタグを考えているうちに書きたかったことを忘れてしまう。
そこで作ったのが Tiny Task Tool です。コマンド名はタイプしやすいように `ttt</code> としました。`
`「一枚の紙」のシンプルさをターミナルで再現することを目指した、ミニマルなタスク管理ツールです。`
`この記事では、ttt</code> のコンセプトと使い方を紹介しつつ、Claude Codeとの協働開発でドキュメント駆動とTDDがいかに効果的だったかをお伝えします。`

`Tiny Task Tool とは</h2> ttt</code>(Tiny Task Tool) は「デジタルなメモ用紙」を目指したTUIタスク管理ツールです。`
`主な特徴</h3>`

一枚の紙: ファイルは常に1つ。「どのファイルに書こう」という選択を排除</li>
今に集中: タスクをすぐ書き出し、完了したらアーカイブ。シンプルな運用</li>
ノード指向: 階層構造のタスクを直感的に扱える。親を完了すれば子も完了</li>
Unix 哲学: フォーカス機能以外は外部エディタやGitに任せる</li> </ul> インストール</h3>
# go install（推奨） go install github.com/yostos/tiny-task-tool@latest # Homebrew brew install yostos/tap/ttt</code></pre>基本的な使い方</h3> ターミナルで ttt</code> と打つだけで、1ページのタスク表がTUIで開きます。 ttt # TUIでタスク表を開く ttt -t "牛乳を買う" # コマンドラインからタスクを追加 ttt sync # git pushでリモートと同期</code></pre> TUIでは e</code> でエディタを開き、a</code> でアーカイブ、q</code> で終了。キーバインドはVim/Emacsユーザー向けにカスタマイズ可能です。 タスクのフォーマット</h3> シンプルなMarkdownチェックボックス形式です。 - [ ] 未完了のタスク - [x] 完了したタスク @done(2026-01-18) - [x] 子タスクも自動で完了 @done(2026-01-18)</code></pre> タスク以外の箇条書きもノードとして挿入できます。タスクをグルーピングするためにセクション（# Task</code> や ## Project A</code>）なども扱えます。 完了したタスクには自動で @done(日付)</code> タグが付き、設定した日数が経過するとarchive.mdに移動します。 なぜ作ったのか</h2> きっかけはZennで見かけた「Markdown Paper という選択肢</a>」という記事でした。ephe.app</a> の「一枚の紙」コンセプトをCLIに持ち込んだ aeph</a> の紹介記事です。 コンセプトには共感しましたが、aephは複数ファイルに対応しており、「一枚の紙」とは少し違うと感じました。そこでaephのソースコードを参考にするのではなく、ゼロから自分のコンセプトで作ることにしました。 既存のツールにも同様の問題がありました。 Todo アプリ: 多機能すぎる。プロジェクト、優先度、タグ…考えているうちに書きたいことを忘れる</li> Markdown エディタ: ファイル名やフォルダを考える必要がある</li> GUI アプリ: ターミナルから離れるコンテキストスイッチが発生する</li> </ol> 単一ファイル、選択肢なし、気を散らすものなし。机の上のメモ用紙のように、「開いて、書いて、終わったら消す」だけの体験が欲しかったのです。 Claude Code との開発体験</h2> このプロジェクトはClaude Codeを活用し、以下のプロセスで開発しました。 コンセプト文書化（concept.md）</li> 詳細仕様策定（specification.md）</li> アーキテクチャ選定（architecture.md）</li> テストコード先行開発</li> 実装</li> テスト自動化</li> </ol> ドキュメント駆動が効いた理由</h3> Claude Codeとの協働で最も効果的だったのは、まずドキュメントを書き、それに従って開発するアプローチでした。 1. concept.md で方向性を固める</h4> 最初に「なぜ作るのか」「何をしないか」を明確にしました。 ### やらないこと - ファイル指定（「どのファイルを開くか」という選択を排除） - 複数ファイル管理（一枚の紙の原則に反する） - ファイル内編集（外部エディタに任せる）</code></pre> 「やらないこと」を明文化したことで、開発中に機能追加の誘惑が来ても「concept.mdに反する」と判断できました。Claudeにも「この機能はconcept.mdの方針に反しますね」とフィードバックを受けられます。 2. specification.md で仕様を詳細化</h4> ユースケース、画面レイアウト、エラー処理まで事前に定義しました。これによりClaudeへの指示が明確になり、生成されるコードの品質が上がりました。 3. architecture.md で技術選定を記録</h4> 「なぜその技術を選んだか」「他の選択肢をなぜ却下したか」を記録しました。後から見返したとき、またClaudeに文脈を伝えるときに役立ちました。基本的に記載方法は Architectural Decision Record（ADR）形式 を採用して記載しています。 以下は言語選定の際の例です。 候補</th> 却下理由</th></tr></thead> Rust</td> 学習コストが高い。所有権/ライフタイムの概念が独特で、AI 駆動開発でコンパイルエラー修正時に堂々巡りするリスク</td></tr> Python</td> PEP 668 により配布が複雑化。起動速度も遅い</td></tr> TypeScript</td> 単一バイナリ配布ができず「摩擦をなくす」原則に反する</td></tr> </tbody></table> TDD が AI 駆動開発と相性が良い理由</h3> テスト駆動開発（TDD）はClaude Codeとの開発で特に威力を発揮しました。 テストファーストのメリット</h4> 期待動作の明確化: テストコードが「仕様書」として機能し、開発前に私が確認できるためClaudeへの指示が曖昧にならない</li> リグレッション防止: AIが生成したコードの変更が既存機能を壊していないか即座に確認</li> リファクタリングの安心感: テストが通れば安心して改善できる</li> </ol> 実際の開発フロー</h4> # 1. まずテストを書く（Red） $ go test ./... # FAIL: TestArchiveCompletedTasks - 期待する動作のテストが失敗 # 2. Claude に実装を依頼 # 「このテストを通す実装をお願いします」 # 3. テストが通ることを確認（Green） $ go test ./... # PASS # 4. リファクタリング # 「この実装をより読みやすくリファクタリングしてください」</code></pre> 特に階層タスクのアーカイブ処理のような複雑なロジックでは、テストケースを先に書いておくことで、エッジケースの考慮漏れを防げました。 Claude Code との対話で心がけたこと</h3> ドキュメントを参照させる:「concept.mdの方針に従って」「specification.mdの仕様通りに」</li> 小さな単位で依頼: 一度に多くを頼まず、テスト→実装→確認のサイクルを回す</li> コミットを細かく: 動作確認できた時点でコミット。戻れるポイントを作る</li> </ol> 技術スタック</h2> 分野</th> 選択</th> 理由</th></tr></thead> 言語</td> Go</td> 単一バイナリ配布、高速起動</td></tr> TUI</td> bubbletea + lipgloss</td> 成熟したエコシステム、Elm アーキテクチャ</td></tr> 設定</td> pelletier/go-toml v2</td> TOML 1.0 準拠、高速</td></tr> テスト</td> testing + testify</td> 標準+簡潔なアサーション</td></tr> </tbody></table> まとめ</h2> ttt</code> は「一枚の紙」という思想にこだわった結果、機能を削ることで価値を磨けたツールになったと思います。私自身も便利に使っています。もっと高機能なツールはたくさんありますが、コンセプトに賛同いただける多くの方に使ってもらえれば幸いです。 Claude Codeとの開発では、ドキュメント駆動 と TDD の組み合わせが非常に効果的でした。 ドキュメント駆動: 要件だけでなく方針を文書化するところから、Claude Codeと協働する</li> TDD: 期待動作を定義し、品質を担保する</li> </ul> 「Claude Codeに任せきり」ではなく「Claude Codeと協働する」開発スタイルとして、このアプローチはおすすめできます。 興味を持っていただけたら、ぜひ使ってみてください。 https://github.com/yostos/tiny-task-tool</a> この記事で紹介したドキュメント（concept.md, specification.md, architecture.md）は GitHub リポジトリの docs/ ディレクトリで公開しています。 Logic ProのAIFファイルをラウドネス正規化してFLACに変換するスクリプト 2026-01-14T00:00:00+00:00 背景</h2> Logic Proでバウンスした音声ファイル(Aiff)をFLACに変換する際、適切な音量に正規化する必要があります。ffmpegのloudnorm</code>フィルタを使うと高品質なラウドネス正規化が可能ですが、最良の結果を得るには2パス処理が推奨されます。 この2パス処理は以下のような手順です。 1回目の実行で音声のラウドネス値を測定</li> 測定された値を確認し、手動で2回目のコマンドにコピー</li> 2回目の実行で測定値を使用して正規化を適用</li> </ol> 毎回この作業を手動で行うのは面倒なので、自動化するスクリプトを作成しました。 スクリプトの内容</h2> 現時点のコードは以下です。Gist</a>でも公開しています。 #!/bin/bash # Script to convert AIF files to FLAC # Uses two-pass loudness normalization method (measure first, then encode with measured values) # # Copyright (c) 2026 yostos # Licensed under the MIT License # https://opensource.org/licenses/MIT set -e VERBOSE=false # Parse options while [[ $# -gt 0 ]]; do case $1 in -v|--verbose) VERBOSE=true shift ;; -h|--help) echo "Usage: $0 [-v|--verbose] <input_file.aif>" echo "" echo "Options:" echo " -v, --verbose Show detailed ffmpeg output" echo " -h, --help Show this help message" exit 0 ;; -) echo "Error: Unknown option $1" echo "Usage: $0 [-v|--verbose] <input_file.aif>" exit 1 ;; ) INPUT_FILE="$1" shift ;; esac done if [ -z "$INPUT_FILE" ]; then echo "Usage: $0 [-v|--verbose] <input_file.aif>" echo "Use -h or --help for more information" exit 1 fi if [ ! -f "$INPUT_FILE" ]; then echo "Error: File '$INPUT_FILE' not found" exit 1 fi # Generate output filename (change extension to .flac) OUTPUT_FILE="${INPUT_FILE%.}.flac" echo "=== Step 1: Measuring loudness... ===" echo # Measure loudness and get JSON output LOUDNESS_JSON=$(ffmpeg -i "$INPUT_FILE" -af "loudnorm=print_format=json" -f null - 2>&1 | grep -A 12 "Parsed_loudnorm") # Extract required values from JSON MEASURED_I=$(echo "$LOUDNESS_JSON" | grep '"input_i"' | awk -F'"' '{print $4}') MEASURED_TP=$(echo "$LOUDNESS_JSON" | grep '"input_tp"' | awk -F'"' '{print $4}') MEASURED_LRA=$(echo "$LOUDNESS_JSON" | grep '"input_lra"' | awk -F'"' '{print $4}') MEASURED_THRESH=$(echo "$LOUDNESS_JSON" | grep '"input_thresh"' | awk -F'"' '{print $4}') TARGET_OFFSET=$(echo "$LOUDNESS_JSON" | grep '"target_offset"' | awk -F'"' '{print $4}') echo "Measurement results:" echo " Input Integrated: $MEASURED_I LUFS" echo " Input True Peak: $MEASURED_TP dBTP" echo " Input LRA: $MEASURED_LRA LU" echo " Input Threshold: $MEASURED_THRESH LUFS" echo " Target Offset: $TARGET_OFFSET LU" echo echo "=== Step 2: Encoding to FLAC... ===" echo # Encode to FLAC using measured values if [ "$VERBOSE" = true ]; then # Verbose mode: show all ffmpeg output ffmpeg -y -i "$INPUT_FILE" \ -af "loudnorm=I=-14:TP=-1:LRA=11:measured_I=$MEASURED_I:measured_TP=$MEASURED_TP:measured_LRA=$MEASURED_LRA:measured_thresh=$MEASURED_THRESH:offset=$TARGET_OFFSET:linear=true:print_format=summary" \ -c:a flac "$OUTPUT_FILE" else # Quiet mode: capture output and show only loudnorm summary FFMPEG_OUTPUT=$(ffmpeg -y -hide_banner -i "$INPUT_FILE" \ -af "loudnorm=I=-14:TP=-1:LRA=11:measured_I=$MEASURED_I:measured_TP=$MEASURED_TP:measured_LRA=$MEASURED_LRA:measured_thresh=$MEASURED_THRESH:offset=$TARGET_OFFSET:linear=true:print_format=summary" \ -c:a flac "$OUTPUT_FILE" 2>&1) FFMPEG_EXIT_CODE=$? # Extract and display loudnorm summary echo "$FFMPEG_OUTPUT" | grep -A 15 "Input Integrated:" | grep -v "^\[" | grep -v "^$" || true # Check for errors if [ $FFMPEG_EXIT_CODE -ne 0 ]; then echo "" echo "Error during encoding (exit code: $FFMPEG_EXIT_CODE)" echo "$FFMPEG_OUTPUT" exit 1 fi fi echo echo "=== Completed ===" echo "Output file: $OUTPUT_FILE" # Display file sizes if command -v du &> /dev/null; then INPUT_SIZE=$(du -h "$INPUT_FILE" | awk '{print $1}') OUTPUT_SIZE=$(du -h "$OUTPUT_FILE" | awk '{print $1}') echo "Input file: $INPUT_SIZE" echo "Output file: $OUTPUT_SIZE" fi</code></pre>使い方</h2> AIFファイルのパスを引数に指定して実行します。 ./aif2flac.sh input.aif</code></pre> 詳細な出力を確認したい場合は-v</code>オプションを付けます。出力ファイルは同じディレクトリに.flac</code>拡張子で保存されます。 loudnormフィルタについて</h2> ffmpegのloudnorm</code>フィルタは、EBU R128規格に基づいたラウドネス正規化を行うためのフィルタです。単純な音量の増減ではなく、人間の聴覚特性を考慮した知覚的な音量の均一化を実現します。 このスクリプトでは以下のパラメータを使用しています。 I=-14</code>: 目標のIntegrated Loudness（LUFS単位）</li> TP=-1</code>: True Peak値の上限（dBTP単位）</li> LRA=11</code>: Loudness Range（LU単位）</li> </ul> I=-14 LUFS</code>は、Spotify、YouTube Music、Apple Musicなどの主要なストリーミングサービスが採用している標準的なラウドネス基準です。世間一般で広く使われているこの基準を参考にすることで、適切な音量バランスを保つことができます。 1パス処理では入力音声の特性を考慮せずに正規化するため、音質劣化の可能性があります。2パス処理では、1回目で測定した入力音声の実際の値を2回目の処理に使用することで、より正確で高品質な正規化が可能になります。 まとめ</h2> Logic Proから書き出した音声ファイルをFLACに変換する際の2パス処理を自動化することで、手動でパラメータをコピーする手間がなくなり、作業効率が大幅に向上しました。 今後は、複数ファイルの一括処理や、ターゲットラウドネス値のカスタマイズなどの機能を追加するかもしれません。 GitHub Actionsでnpmパッケージ公開を自動化する - Trusted Publishingで実現するトークンレス運用 2025-12-05T00:00:00+00:00 本記事では、私が開発しているjrnl-mcp</a>パッケージで実装した、 GitHubが発表したnpmの認証強化</a> 対応の Trusted Publishing (OIDC) を使用したトークン管理不要の自動公開について記載しています。 npmの認証変更の背景</h2> GitHubは2025年9月29日に、npmのセキュリティ強化として以下の変更を発表しました。 Classic Access Tokenの廃止</li> Trusted Publishing (OIDC) またはGranular Access Tokenへの移行推奨</li> より細かい権限管理の実現</li> </ul> 移行先として2つの選択肢があります。 Granular Access Token</li> Trusted Publishing (OIDC)</li> </ol> Granular Access Tokenは、従来のトークン方式を改良したものでパッケージごとの権限管理が可能となっていますが、定期的なトークンのローテーションが必要です。 Trusted Publishingはトークンを完全に排除した新しい認証方式で、公開を自動化しトークンを完全に排除したものです。 jrnl-mcpでは、トークン管理の手間を完全に排除できる Trusted Publishing を採用しました。 自動公開の仕組み</h2> 全体のフロー</h3> jrnl-mcpでは、以下のフローで自動公開を実現しています。 GitHubでリリースを作成</li> GitHub Actionsが自動起動</li> 依存関係のインストールとテストを実行</li> npmへ自動公開</li> </ol> この仕組みにより、リリース作成だけでパッケージの公開が完了します。 GitHub Actionsの設定</h3> 実際に使用しているワークフロー設定は以下の通りです。 name: Publish to npm on: release: types: [published] permissions: contents: read id-token: write jobs: publish: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: "20" registry-url: "https://registry.npmjs.org" - name: Install dependencies run: npm ci - name: Run tests run: npm run test:ci - name: Publish to npm run: npm publish --provenance --access public</code></pre> 重要なポイントは、 GitHubのリリース機能を使用することで、手動でのトリガーが可能になる。これにより、意図しないタイミングでの公開を防ぐ。</li> permissions</code>の設定により、GitHub Actionsはnpmに対して一時的なOIDCトークンを発行・認証する。長期的なトークンをSecretに保存する必要がない。</li> npm publish --provenance --access public</code>により自動的にprovenance（出所証明）が生成され、パッケージがどのリポジトリから公開されたか検証可能となる。</li> npm run test:ci</code>により公開前のテストを自動化する。</li> </ol> Trusted Publishing の設定方法</h2> Trusted Publishingを使用する場合、npm側での設定が必要です。 1. npm でパッケージを公開</h3> まず、通常の方法で初回のパッケージを公開します（トークンを使用）。npm側でパッケージが存在している必要があるためです。 2. npm で Trusted Publishing を設定</h3> npm のパッケージ設定</a>にアクセス</li> 公開したパッケージの"Settings"タブを開く</li> "Publishing access"セクションで"Add a publisher"を選択</li> GitHub Actionsを選択し、以下を設定する Repository: <username>/<repository-name></code>（例: yostos/jrnl-mcp</code>）</li> Workflow: ワークフローファイル名（例: publish.yml</code>）</li> Environment: 未指定（デフォルト）または特定の環境名</li> </ul> </li> </ol> 3. GitHub Actions の設定</h3> 前述のワークフロー設定で、id-token: write</code> 権限を付与するだけで完了です。トークンをSecretに保存する必要はありません。 トークンベースとの比較</h3> Trusted Publishingを使用することで、以下の作業が不要になります。 npmトークンの作成と保存</li> GitHub Secretsへのトークン登録</li> トークンの定期的なローテーション（Granular Access Tokenの場合、最大90日ごと）</li> トークン漏洩のリスク管理</li> </ul> まとめ</h2> Trusted Publishing (OIDC) とGitHub Actionsを使用したnpmパッケージの自動公開により、以下のメリットが得られました。 公開作業の効率化</li> トークン管理の完全な排除</li> セキュリティの向上</li> 品質の担保</li> 透明性の確保（自動provenance生成）</li> </ul> 特に、Trusted Publishingの導入により、トークンの定期的なローテーションや漏洩リスクの心配が不要になり、セキュリティと運用性が大幅に向上しました。npmパッケージを公開している方は、ぜひTrusted Publishingへの移行とGitHub Actionsによる自動化を検討してみてください。 Granular Access Tokenでもセキュリティは向上しますが、定期的なローテーション（最大90日ごと）が必要なため、可能であればTrusted Publishingの使用を推奨します。 参考リンク</h2> Strengthening npm security: Important changes to authentication and token management</a></li> jrnl-mcp GitHub Repository</a></li> npm Documentation: About access tokens</a></li> </ul> Apple Silicon時代のMacバックアップ最新戦略 2025-04-18T00:00:00+00:00 Macのバックアップ戦略</h2> macOSはOS自体がTimeMachineという自動バックアップ機能を持っています。以下のような特徴を持っています。 特徴: macOSに標準搭載、独自形式でデータを保存</li> メリット: 設定が簡単、自動バックアップ、過去バージョンへのアクセス</li> デメリット: 独自形式のため通常のFinderからのアクセスが困難</li> アプローチ: 問題発生時はリカバリーからOSインストール後、Migration Assistantでデータ復元</li> </ul> iMacを使っていた時は使っていましたが、Macbookを使うようになってから TimeMachineの使用を止めました。理由は、バックアップ用にディスクが常にマウントされているとは限らないので「自動バックアップ」の恩恵が相対的に薄く、加えて独自形式のためTimeMachineのメカニズムでしかバップアップにアクセスできないためです。 Apple Silicon時代のバックアップの変化</h2> TimeMachineを使用しない替わりに、長らくSuperDuper</a> やCarbon Copy Cloner</a>を使いディスクごと完全なクローンを取っていました。完全なクローンはブート可能なので、リカバリーの際にはクローンディスクから macOSをブートしてリカバリーを行うことができました。 しかし、Apple Silicon搭載のMac（M1/M2/M3チップ）ではIntelが使われていた時代と比較してシステムアーキテクチャが大きく変わりました。 主な変更点は次の通りです。 OSが読み取り専用として保護されるようになった</li> リカバリー機能がより強化された（Recovery・Fallback Recoveryが内蔵）</li> 外部ドライブからの起動に制限が追加された</li> </ul> バックアップ戦略も見直す必要が出てきました。このためBootableな完全ディスククローンという戦略は以前ほど重要ではなくなりました。 推奨バックアップ戦略</h2> 次のようなバックアップ戦略を変更することが必要です。 データ中心のバックアップ: OSではなく、ユーザーデータを確実に保護する</li> SuperDuperの場合はBackup - User files</code>オプションが効率的</li> TimeMachineを使う場合は、同様にデータのバックアップに重点を置く</li> </ul> </li> リカバリー戦略: 問題発生時：リカバリーモードから起動（⌘+Rキー）</li> OSをクリーンインストール</li> Migration Assistantを使ってバックアップからデータを復元</li> </ol> </li> </ul> </li> ストレージの選択: ユーザーデータのみをバックアップする場合、Mac本体と同程度の容量で十分</li> 頻繁にアクセスする場合はSSD、コスト重視ならHDDを選択</li> NASを使用すれば、ネットワーク経由で自動バックアップも可能</li> </ul> </li> </ol> SuperDuperとTimeMachineの選択基準</h2> 私自身はSuperDuperを使用していますが、有償のソフトウェアですしApple謹製の TimeMachineを使いたい方もいると思います。次のような観点で選択すればよいと思います。 SuperDuperを選ぶ場合: バックアップから直接ファイルにアクセスしたい</li> 標準ファイルシステムでの管理を好む</li> 選択的なバックアップをしたい</li> バックアップスケールや方法を自分で調整したい</li> </ul> </li> TimeMachineを選ぶ場合: 設定の簡単さを重視</li> 過去バージョンへの簡単なアクセスが必要</li> macOSに標準搭載の機能のみで完結させたい</li> </ul> </li> </ul> まとめ</h2> Apple Silicon時代では、起動可能なバックアップよりも「確実にデータを保護し、必要時に復元できる」戦略が重要です。OSはリカバリーモードから再インストールし、大切なユーザーデータは確実にバックアップしておくことで、トラブル時も迅速に復旧できます。 SuperDuperの最新ベータ版ではブータビリティの改善が進んでいますが、現実的な運用としてはユーザーデータに焦点を当てた戦略が効率的です。 また、私はpCloudも使用しているため、特に重要なファイルはpCloud上で作業するようにしています。過去30日分のリビジョンが保存されますし、クラウドからいつでも取り出せます。 家庭用途では、特にストレージコストを考慮すると、データ中心の定期的バックアップとクラウドなどへの直近のデータの保管を併用すれば十分な保護が可能です。 ChromaLensCLI: Command Line Color Accessibility Validation 2025-01-25T00:00:00+00:00 とりあえず色覚異常の方にも画像が正しく認識できてるか確認するためのツール ChromaLens CLI</code>を作ってみた。 ChromaLens CLIの使い方</h2> 使い方は、次の通り。 ./chromalens input.jpg output.jpg --type tritanopia</code></pre> これで色覚異常の方が実際どのようにインプットとなる画像が見えているかシミュレーションした画像が出力されます。 type</code> オプションの指定は次の通りです。 protanopia (1型色覚)</li> deuteranopia (2型色覚)</li> tritanopia (3型色覚)</li> </ul> ChromeLens CLIの環境設定</h4> 以下は、venvでPythonの仮想環境を作って必要なパッケージをインストールする手順です。 python3 -m venv venv source venv/bin/activate.fish pip install numpy Pillow</code></pre> 以下が実際のコードです。chromalens</code>というファイル名で保管ください。授業中に書いたコードなので、エラー処理などは省いています。 #!/usr/bin/env python3 from PIL import Image class ColorVisionSimulator: MATRICES = { 'protanopia': np.array([ [0.567, 0.433, 0.000], [0.558, 0.442, 0.000], [0.000, 0.242, 0.758] ]), 'deuteranopia': np.array([ [0.625, 0.375, 0.000], [0.700, 0.300, 0.000], [0.000, 0.300, 0.700] ]), 'tritanopia': np.array([ [0.950, 0.050, 0.000], [0.000, 0.433, 0.567], [0.000, 0.475, 0.525] ]) } def simulate(self, image_path, output_path, cvd_type): if cvd_type not in self.MATRICES: raise ValueError(f"Unsupported CVD type. Choose from: {', '.join(self.MATRICES.keys())}") # 画像を読み込み img = Image.open(image_path) # RGBAの場合はRGBに変換 if img.mode == 'RGBA': img = img.convert('RGB') # NumPy配列に変換 img_array = np.array(img) # 色変換行列を適用 matrix = self.MATRICES[cvd_type] shape = img_array.shape pixels = img_array.reshape(-1, 3) converted = np.dot(pixels, matrix.T) # 値を0-255の範囲に収める converted = np.clip(converted, 0, 255) converted = converted.reshape(shape) # 画像として保存 result = Image.fromarray(converted.astype('uint8'), 'RGB') result.save(output_path) def main(): parser = argparse.ArgumentParser(description='Color Vision Deficiency Simulator') parser.add_argument('input', help='Input image path') parser.add_argument('output', help='Output image path') parser.add_argument('--type', '-t', choices=['protanopia', 'deuteranopia', 'tritanopia'], required=True, help='Type of color vision deficiency') args = parser.parse_args() simulator = ColorVisionSimulator() try: simulator.simulate(args.input, args.output, args.type) print(f"Simulation complete: {args.output}") except Exception as e: print(f"Error: {str(e)}") exit(1) if name == 'main': main()</code></pre> How to Merge and Optimize Your PDF Files 2025-01-10T00:00:00+00:00 Bypassing PDF Password Protection</h2> While the DJI Neo user manual is provided in PDF format, it's password-protected, preventing any modifications or merging. Here's how to bypass the password protection on a Mac: Open the PDF in the Preview app</li> Select "Print" from the File menu (note: not "Export")</li> Choose "Save as PDF" and specify the destination</li> </ol> This process will create a new PDF without password protection. Merging PDFs</h2> While this can be done with Ghostscript</code> (mentioned later), we'll use pdftk</code> for its advantages: Preserves PDF internal structure (table of contents, bookmarks, links, etc.)</li> Operates at the binary level, preventing quality degradation</li> (Although not relevant for this case) Offers flexible operations like page rotation and reordering</li> </ul> Here's how to merge PDFs: # Install pdftk (on Mac) brew install pdftk-java # Merge PDFs pdftk input1.pdf input2.pdf cat output merged.pdf</code></pre>PDF Optimization</h2> After merging, I found that the file size exceeded 40MB, which was too large to upload to MLIT's DIPS2.0 (Drone/UAS Information Platform System). To resolve this, I used Ghostscript for optimization: # Install Ghostscript (on Mac) brew install ghostscript # Optimize PDF gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/screen -dNOPAUSE -dQUIET -dBATCH -sOutputFile=output.pdf input.pdf</code></pre> The -dPDFSETTINGS</code> option allows you to adjust the compression level: /screen</code>: For screen display (72dpi) - smallest file size</li> /ebook</code>: For e-books (150dpi) - balanced compression</li> /printer</code>: For printing (300dpi)</li> /prepress</code>: For high-quality printing (highest quality)</li> </ul> Making PDF Searchable</h2> Scanned PDFs aren't searchable. Use these Linux/Mac commands for OCR instead of expensive software: brew install ocrmypdf brew install tesseract-lang # OCR with image optimization ocrmypdf -l jpn --optimize 3 input.pdf output.pdf</code></pre>Creating Table of contents</h2> Scanned PDFs often lack a table of contents. Instead of buying expensive PDF software, use these Linux/Mac commands: # Install pdftk (on Mac) brew install pdftk-java # Extract metadata pdftk input.pdf dump_data_utf8 > metadata.txt</code></pre> Open metadata.txt in your editor and add bookmark locations in this format: BookmarkBegin BookmarkTitle: Chapter 1 BookmarkLevel: 1 BookmarkPageNumber: 1 BookmarkBegin BookmarkTitle: Chapter 2 BookmarkLevel: 1 BookmarkPageNumber: 10</code></pre> Then apply the metadata to create a PDF with a table of contents: # Apply edited metadata pdftk input.pdf update_info_utf8 metadata.txt output output.pdf</code></pre>Conclusion</h2> With these steps, I successfully optimized the PDF and completed the drone registration. However, it seems rather inefficient to require individual manual submissions for DJI drones, which are widely used. This feels like typical bureaucratic red tape. Finally, while this may only be relevant for Japanese users, I'm sharing the prepared DJI Neo manual that meets DIPS2.0 requirements here: Download</a> A Failed Experiment: Using OpenCV to Read Printed Dates from Scanned Photos 2025-01-06T00:00:00+00:00 Organizing Old Photographs</h3> I recently purchased a scanner at the end of the year to digitize old photographs. The photographs have dates printed on them, and I've been manually setting these dates in the EXIF information using ExifTool. I use Hazel to organize image files, and I've already created a tool that updates file creation dates that Hazel can read with the shooting dates from EXIF data. However, since setting EXIF information manually is time-consuming, I explored the possibility of automating this process using OpenCV. Date Reading Tool</h3> Below is a script that uses OpenCV to read dates from images and set them using ExifTool. #!/usr/bin/env python3 from datetime import datetime def preprocess_image(image_path): """ Extract and process the date stamp portion from the image """ # Load image img = cv2.imread(image_path) height, width = img.shape[:2] # Crop the bottom right region x1 = int(width 0.65) y1 = int(height 0.75) cropped = img[y1:height, x1:width] # Split channels b, g, r = cv2.split(cropped) # Enhance red channel red_emphasis = cv2.subtract(r, cv2.max(b, g)) # Enhance contrast using CLAHE clahe = cv2.createCLAHE(clipLimit=3.0, tileGridSize=(8,8)) enhanced = clahe.apply(red_emphasis) # Strong thresholding _, binary = cv2.threshold(enhanced, 30, 255, cv2.THRESH_BINARY) # Remove noise kernel = np.ones((2,2), np.uint8) cleaned = cv2.morphologyEx(binary, cv2.MORPH_OPEN, kernel) # Detect and filter contours contours, _ = cv2.findContours(cleaned, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) # Filter by area mask = np.zeros_like(cleaned) min_area = 10 max_area = 500 for contour in contours: area = cv2.contourArea(contour) if min_area < area < max_area: cv2.drawContours(mask, [contour], -1, (255), -1) # Resize to 4x result = cv2.resize(mask, None, fx=4, fy=4, interpolation=cv2.INTER_CUBIC) # Save debug images debug_dir = os.path.join(os.path.dirname(image_path), 'debug') os.makedirs(debug_dir, exist_ok=True) basename = os.path.basename(image_path) cv2.imwrite(os.path.join(debug_dir, f'cropped_{basename}'), cropped) cv2.imwrite(os.path.join(debug_dir, f'red_emphasis_{basename}'), red_emphasis) cv2.imwrite(os.path.join(debug_dir, f'enhanced_{basename}'), enhanced) cv2.imwrite(os.path.join(debug_dir, f'binary_{basename}'), binary) cv2.imwrite(os.path.join(debug_dir, f'result_{basename}'), result) return result def extract_date_from_image(image_path): """Extract date from image using OCR""" # Preprocess image processed_image = preprocess_image(image_path) # OCR configuration for single line text custom_configs = [ '--psm 6 -c tessedit_char_whitelist="0123456789\' "', # Uniform text block '--psm 7 -c tessedit_char_whitelist="0123456789\' "', # Single text line '--psm 8 -c tessedit_char_whitelist="0123456789\' "', # Single word '--psm 10 -c tessedit_char_whitelist="0123456789\' "' # Single character ] for config in custom_configs: # Run OCR text = pytesseract.image_to_string(processed_image, config=config) text = text.strip() print(f"OCR result (config={config}): [{text}]") # Normalize spaces text = ' '.join(text.split()) # Simple pattern matching pattern = r"'?(\d{2})\s(\d{1,2})\s(\d{1,2})" match = re.search(pattern, text) if match: try: year = int(match.group(1)) month = int(match.group(2)) day = int(match.group(3)) # Handle 2000s year = 2000 + year if year < 50 else 1900 + year if 1 <= month <= 12 and 1 <= day <= 31: return datetime(year, month, day) except ValueError: continue return None def set_exif_date(image_path, date): """Set EXIF date information using ExifTool""" if not date: print(f"No date found in: {image_path}") return False date_str = date.strftime("%Y:%m:%d") # EXIF tags to set exif_tags = [ "DateTimeOriginal", "CreateDate", "ModifyDate" ] command = ["exiftool", "-overwrite_original_in_place"] for tag in exif_tags: command.extend([f"-{tag}={date_str}"]) command.append(image_path) try: subprocess.run(command, check=True, capture_output=True) print(f"Date set successfully: {image_path} -> {date_str}") return True except subprocess.CalledProcessError as e: print(f"Failed to set EXIF information: {e}") return False def process_images(directory): """Process all images in the specified directory""" processed = 0 failed = 0 for filename in os.listdir(directory): if filename.lower().endswith(('.png', '.jpg', '.jpeg')): image_path = os.path.join(directory, filename) date = extract_date_from_image(image_path) if set_exif_date(image_path, date): processed += 1 else: failed += 1 print(f"\nProcessing complete:") print(f"Success: {processed}") print(f"Failed: {failed}") def main(): if len(sys.argv) != 2: print("Usage: photodate <image_directory>") sys.exit(1) directory = sys.argv[1] if not os.path.isdir(directory): print("Specified path is not a valid directory") sys.exit(1) process_images(directory) if name == "main": main()</code></pre>Results</h3> I tested the script on 27 scanned photographs. Out of 27 images, the script only detected dates in 4 images, and among those, only 1 date was correctly recognized. Well, this isn't practical enough to use. A Command to Sync EXIF Data with File System Timestamps 2024-12-30T00:00:00+00:00 The scanner's performance has been impressive - it handled even my old San Francisco business trip photos from 2001 beautifully, producing crisp, clear scans. Setting EXIF Information</h2> Unlike photos taken with a digital camera, scanned images don't come with proper EXIF data. To preserve the actual capture dates of these photos, I used exiftool from the command line to set the correct EXIF information: # Example: Setting the original capture date exiftool "-DateTimeOriginal=2001:04:15 10:00:00" photo.jpg</code></pre> This command successfully embeds the correct capture date in the photo's EXIF data. The Photo Organization</h2> For managing my photo files, I rely on Hazel, a powerful file organization tool for Mac. Hazel offers some fantastic automation features: Filtering based on file creation and modification dates</li> Automatic folder organization</li> Smart file renaming</li> </ul> However, Hazel has one limitation that's been bugging me: it can't directly read EXIF data. This means that even though I've carefully added the correct capture dates to the EXIF data, I can't use this information for Hazel's automated organization. The Solution: adj-photodate Script</h2> To bridge this gap, I created a script that syncs EXIF information with the file system timestamps (creation and modification dates). This enables Hazel to organize photos based on their actual capture dates. The script provides the following features: Syncs DateTimeOriginal</code> from EXIF to file system timestamps</li> Includes a dry-run mode for previewing changes</li> Handles batch processing of multiple files</li> Supports recursive directory processing</li> </ul> Installation</h3> Create a file named "adj-photodate" and paste the following script: adj-photodate</a></li> </ul> </li> Make it executable: chmod +x adj-photodate</code></pre></li> Optionally, move it to your path: cp adj-photodate ~/bin/</code></pre> Dependencies: </li> </ol> bash shell</li> exiftool</li> </ul> Usage</h3> # Process a single file ./adj-photodate photo.jpg # Preview changes with dry-run ./adj-photodate -n photo.jpg # Process all JPEG files in a directory recursively ./adj-photodate -r ~/Pictures/Scanned</code></pre> To see available options: ./adj-photodate --help</code></pre> コマンドラインで画像のExif修正 2024-08-23T00:00:00+00:00 デジカメの日付の設定を間違えExifの日付を修正したかったが、 AppStoreから余計なアプリをインストールしたくなかったので、Homebrewでexiftoolをインストールして修正。 # Install exiftool using Homebrew brew install exiftool # Confirm dates of exif exiftool R0000001.jpg ExifTool Version Number : 12.76 File Name : R0000001.JPG Directory : . File Size : 12 MB File Modification Date/Time : 2024:08:26 12:42:29+09:00 File Access Date/Time : 2024:08:26 12:43:26+09:00 File Inode Change Date/Time : 2024:08:26 12:43:24+09:00 File Permissions : -rwx------ File Type : JPEG File Type Extension : jpg MIME Type : image/jpeg Exif Byte Order : Little-endian (Intel, II) (Output truncated for brevity) # Modify dates of exif exiftool -Alldates='2024:08:23 12:11:00' -overwrite_original ./</code></pre>

ドキュメント駆動が効いた理由</h3>
Claude Codeとの協働で最も効果的だったのは、まずドキュメントを書き、それに従って開発する</strong>アプローチでした。</p>

2. specification.md で仕様を詳細化</h4>
ユースケース、画面レイアウト、エラー処理まで事前に定義しました。これによりClaudeへの指示が明確になり、生成されるコードの品質が上がりました。</p>

TDD が AI 駆動開発と相性が良い理由</h3>
テスト駆動開発（TDD）はClaude Codeとの開発で特に威力を発揮しました。</p>

Logic ProのAIFファイルをラウドネス正規化してFLACに変換するスクリプト

GitHub Actionsでnpmパッケージ公開を自動化する - Trusted Publishingで実現するトークンレス運用

Trusted Publishing の設定方法</h2>
Trusted Publishingを使用する場合、npm側での設定が必要です。</p>

1. npm でパッケージを公開</h3>
まず、通常の方法で初回のパッケージを公開します（トークンを使用）。npm側でパッケージが存在している必要があるためです。</p>

3. GitHub Actions の設定</h3>
前述のワークフロー設定で、`id-token: write</code> 権限を付与するだけで完了です。トークンをSecretに保存する必要はありません。</p>`

参考リンク</h2>

Strengthening npm security: Important changes to authentication and token management</a></li>
jrnl-mcp GitHub Repository</a></li>
npm Documentation: About access tokens</a></li> </ul>

Apple Silicon時代のMacバックアップ最新戦略

ChromaLensCLI: Command Line Color Accessibility Validation

How to Merge and Optimize Your PDF Files

A Failed Experiment: Using OpenCV to Read Printed Dates from Scanned Photos

Results</h3>
I tested the script on 27 scanned photographs.</p>
Out of 27 images, the script only detected dates in 4 images, and among those, only 1 date was correctly recognized.</p>
Well, this isn't practical enough to use.</p>

A Command to Sync EXIF Data with File System Timestamps

コマンドラインで画像のExif修正

Coded Chords - CLI

gyrotriage — DJIドローン映像のブレを診断し、Gyroflowのパラメータを自動推定するツール

もしかしてだけど、あれって日本最古のアスキーアートだったんじゃないの？

多機能Todoに疲れた人へ ─「一枚の紙」だけのタスク管理CLI

Coded Chords - CLI

gyrotriage — DJIドローン映像のブレを診断し、Gyroflowのパラメータを自動推定するツール

もしかしてだけど、あれって日本最古のアスキーアートだったんじゃないの？

フォントテーブルの構築</h3> 95個の印字可能ASCII文字（スペース 0x20</code> からチルダ 0x7E</code> まで）について、それぞれ8x8ドットのビットマップパターンを持っています。</p>

8x8ブロックとフォントパターンの照合</h3> ここが核心部分です。画像から切り出した8x8ブロックを、95文字すべてのフォントパターンと比較し、最も「形が近い」文字を見つけます。</p>

多機能Todoに疲れた人へ ─「一枚の紙」だけのタスク管理CLI

ドキュメント駆動が効いた理由</h3> Claude Codeとの協働で最も効果的だったのは、まずドキュメントを書き、それに従って開発する</strong>アプローチでした。</p>

2. specification.md で仕様を詳細化</h4> ユースケース、画面レイアウト、エラー処理まで事前に定義しました。これによりClaudeへの指示が明確になり、生成されるコードの品質が上がりました。</p>

TDD が AI 駆動開発と相性が良い理由</h3> テスト駆動開発（TDD）はClaude Codeとの開発で特に威力を発揮しました。</p>

Logic ProのAIFファイルをラウドネス正規化してFLACに変換するスクリプト

GitHub Actionsでnpmパッケージ公開を自動化する - Trusted Publishingで実現するトークンレス運用

npmの認証変更の背景</h2> GitHubは2025年9月29日に、npmのセキュリティ強化として以下の変更を発表しました。</p> Classic Access Tokenの廃止</li> Trusted Publishing (OIDC) またはGranular Access Tokenへの移行推奨</li>

自動公開の仕組み</h2> 全体のフロー</h3> jrnl-mcpでは、以下のフローで自動公開を実現しています。</p>

全体のフロー</h3> jrnl-mcpでは、以下のフローで自動公開を実現しています。</p>

Trusted Publishing の設定方法</h2> Trusted Publishingを使用する場合、npm側での設定が必要です。</p>

1. npm でパッケージを公開</h3> まず、通常の方法で初回のパッケージを公開します（トークンを使用）。npm側でパッケージが存在している必要があるためです。</p>

3. GitHub Actions の設定</h3> 前述のワークフロー設定で、id-token: write</code> 権限を付与するだけで完了です。トークンをSecretに保存する必要はありません。</p>

まとめ</h2> Trusted Publishing (OIDC) とGitHub Actionsを使用したnpmパッケージの自動公開により、以下のメリットが得られました。</p>

参考リンク</h2> Strengthening npm security: Important changes to authentication and token management</a></li> jrnl-mcp GitHub Repository</a></li> npm Documentation: About access tokens</a></li> </ul>

Apple Silicon時代のMacバックアップ最新戦略

Macのバックアップ戦略</h2> macOSはOS自体がTimeMachine</strong>という自動バックアップ機能を持っています。 以下のような特徴を持っています。</p>

ChromaLensCLI: Command Line Color Accessibility Validation

How to Merge and Optimize Your PDF Files

Bypassing PDF Password Protection</h2> While the DJI Neo user manual is provided in PDF format, it's password-protected, preventing any modifications or merging. Here's how to bypass the password protection on a Mac:</p>

Merging PDFs</h2> While this can be done with Ghostscript</code> (mentioned later), we'll use pdftk</code> for its advantages:</p>

A Failed Experiment: Using OpenCV to Read Printed Dates from Scanned Photos

Results</h3> I tested the script on 27 scanned photographs.</p> Out of 27 images, the script only detected dates in 4 images, and among those, only 1 date was correctly recognized.</p> Well, this isn't practical enough to use.</p>

A Command to Sync EXIF Data with File System Timestamps

Setting EXIF Information</h2> Unlike photos taken with a digital camera, scanned images don't come with proper EXIF data. To preserve the actual capture dates of these photos, I used exiftool from the command line to set the correct EXIF information:</p>

The Photo Organization</h2> For managing my photo files, I rely on Hazel, a powerful file organization tool for Mac. Hazel offers some fantastic automation features:</p>

コマンドラインで画像のExif修正

ドキュメント駆動が効いた理由</h3>
Claude Codeとの協働で最も効果的だったのは、まずドキュメントを書き、それに従って開発する</strong>アプローチでした。</p>

2. specification.md で仕様を詳細化</h4>
ユースケース、画面レイアウト、エラー処理まで事前に定義しました。これによりClaudeへの指示が明確になり、生成されるコードの品質が上がりました。</p>

TDD が AI 駆動開発と相性が良い理由</h3>
テスト駆動開発（TDD）はClaude Codeとの開発で特に威力を発揮しました。</p>

Trusted Publishing の設定方法</h2>
Trusted Publishingを使用する場合、npm側での設定が必要です。</p>

1. npm でパッケージを公開</h3>
まず、通常の方法で初回のパッケージを公開します（トークンを使用）。npm側でパッケージが存在している必要があるためです。</p>

3. GitHub Actions の設定</h3>
前述のワークフロー設定で、`id-token: write</code> 権限を付与するだけで完了です。トークンをSecretに保存する必要はありません。</p>`

参考リンク</h2>

Strengthening npm security: Important changes to authentication and token management</a></li>
jrnl-mcp GitHub Repository</a></li>
npm Documentation: About access tokens</a></li> </ul>

Results</h3>
I tested the script on 27 scanned photographs.</p>
Out of 27 images, the script only detected dates in 4 images, and among those, only 1 date was correctly recognized.</p>
Well, this isn't practical enough to use.</p>