oka-projectのブログで何を残すか｜編集方針

結果だけでは残らないもの

oka-projectでは、Webサービスや小さなツールをつくっています。完成したものは制作物一覧やツールサイトに置いていますが、そこに載るのはうまくいった結果だけです。

実際には、その手前にたくさんの判断があります。なぜその方式を選んだのか、何を試してやめたのか、どこで詰まったのか。これらは完成物を見ても分かりませんし、時間が経つと自分でも忘れます。

公開する記事の基準

何を書くか

• 開発ログ — つくっている途中の話。設計の判断とその理由
• 技術 — 実際に動かして分かったこと。ドキュメントに書いていない挙動や、ハマった罠
• 考えたこと — 方針や価値観の整理
• リリース — 新しいものを公開したときの背景

書く基準

実際に手を動かして確かめたことだけを書きます。 「たぶんこうだろう」は書きません。試していないことは「試していない」と書きます。

うまくいかなかった話も残します。個人開発の記録として、失敗した選択肢が書いてあるほうが後から役に立つからです。

公開前に「この記事でしか得られないもの」を確認する

記事が書き上がっていても、公開予定日が来たという理由だけでは公開しません。

公開前に、この記事を読むことで新しく得られるものを1文で説明できるかを確認します。説明できない場合は、検索結果にある一般論を整理しただけになっていないかを見直します。

単独記事として残す目安は、次のどれかがあることです。

• 自分で条件を固定して行った実測・検証
• 公式仕様や一次資料まで遡って確認した差分
• oka-projectの実データや運用結果
• 比較対象と評価軸を固定した独自比較
• 実装・運用で失敗した過程と、そこから変えた判断
• 読者が同じ順番で試せる再現可能な切り分け

逆に、これらを追加できず、既存記事と同じ検索意図を扱っている場合は、無理に1URL増やさず既存記事へ統合します。

文字数は完成条件にしません。800字でも一次資料の変更点を正確に確認できる記事なら残します。長文でも一般論の言い換えが続くなら、削るか統合します。

新しく書くより、既存記事を強くする

公開本数や更新頻度を維持するために記事を増やすことはしません。

同じテーマの記事がすでにある場合は、まず既存記事へ実測、一次資料、比較結果、失敗例を追加できないか検討します。新しいURLを作るのは、検索意図と読後に得られる情報が既存記事から明確に分かれる場合だけです。

たとえば「画像を圧縮する方法」を一般論のまま複数に分けるより、同じ原画像をJPEG・PNG・WebPで処理し、容量・透明度・見た目・失敗例を同じ条件で残した実測記事を1本作る方を優先します。

同様に、Markdownの貼り付け問題では、媒体ごとの説明を増やすだけでなく、同じテスト原稿をGoogle Docs、WordPress、note、Wordへ移し、見出し・表・コードなどがどこまで保持されるかを同じ評価軸で比べる方を優先します。

何を書かないか

このブログでは、検索されそうだからという理由だけで、体験も一次資料もない一般論を増やすことは避けます。

書かない対象は主に次のようなものです。

• 実際に確認していない製品・機能を、使ったように説明する記事
• 出典をたどれない数字や「○%改善」のような根拠のない効果
• 一次資料を読まず、別の記事を言い換えただけのまとめ
• 仕様が変わりやすいテーマを、確認日なしで断定する説明
• oka-projectのツールを使うこと自体を目的にした比較記事

公式機能やOS標準機能だけで解決できる場合は、そちらを先に案内します。自分のツールが最短経路ではないなら、無理に紹介しません。

調べる記事では、一次資料と限界を残す

Web・AI・ソフトウェアの仕様を扱う記事では、できる限り公式ドキュメント、RFC、W3C仕様、論文、運営主体の発表まで遡ります。

一方、一次資料があるからといって結論まで自動的に正しくなるわけではありません。

たとえば、

• 調査対象が限定されている
• ベンチマーク環境が1台だけ
• コミュニティ報告であり公式仕様ではない
• 2026年時点の仕様で、将来変わる可能性がある

といった条件は本文中に残します。

「分からない」「この資料だけでは断定できない」という結論も、そのまま書きます。

ツールの記事では、標準機能を先に確認する

oka-projectではブラウザで使えるツールも公開しています。

ただし、ツールの記事では最初から自作ツールへ誘導しません。

1枚の画像を縮めるだけならOS標準機能、Google DocsだけへMarkdownを移すならGoogle Docsの標準機能、GitHub READMEの最終確認ならGitHub本体というように、目的に一番近い方法を先に確認します。

自作ツールは、

• 複数の処理をまとめたい
• 同じ作業を繰り返す
• 複数の公開先へ変換する
• ファイルを外部サーバーへ送らず処理したい

など、標準機能だけでは手間が残る場合に候補として置きます。

更新したら、古い説明も直す

WebサービスやAI機能は変わります。

新しい公式仕様を確認したとき、既存記事の前提が古くなっていれば、新記事を増やすより先に既存記事を直します。

特に、

• Google・Microsoft・WordPressなどの編集機能
• AI検索・crawler・robots.txt
• 各サービスの画像サイズ
• ブラウザAPI
• セキュリティやプライバシーに関わる仕様

は、確認日と一次資料を意識して更新します。

このブログを「制作物の説明書」だけにしない

ツールへの入口は重要ですが、それだけではサイトの価値が製品の数に依存します。

そこで、実際に作ったものから生まれた疑問や、Webの仕組み自体を調べた記事も残します。

たとえば、ブラウザがなぜローカルファイルやGPUまで扱えるようになったのか、robots.txtがなぜ30年以上残ったのか、Webページはどれくらい消えるのか、といったテーマです。

こうした記事では、無理にYomuやKarukuへ着地させません。関連があるときだけ内部リンクし、調査そのものが読後価値になることを優先します。

この方針を適用した記事の例

方針だけでは抽象的なので、実際の記事では次のように使い分けています。

• ChatGPTのコピペで書式が崩れる原因と直し方
  Google Docs・Word・WordPressなどの標準機能を先に確認し、Yomuを使う条件を限定しています。
• Markdownをブラウザだけでプレビューする方法
  Viewerだけを勧めず、GitHub・ローカルエディタ・Yomuを目的別に分けています。
• ブラウザ完結ツールの「送信しない」を、約束ではなく構造にする
  「安全です」という宣伝文句ではなく、CSP・Network通信・ブラウザ内処理という確認可能な構造で説明しています。
• ブラウザはいつから「アプリ」になったのか
  File API・IndexedDB・Web Workers・WebAssembly・WebGPUなどを一次資料まで遡り、一つの技術だけを理由にしないよう整理しています。

これらも、仕様変更やより強い一次資料が見つかれば更新します。

最終的に残したいのは「判断の根拠」

完成したツールは更新されます。UIも変わります。使わなくなる技術もあります。

そのときに残したいのは、「この機能を作った」という結果だけではなく、

• 何が問題だったか
• どの資料を見たか
• 何を比較したか
• なぜその方法を選んだか
• どこまで確認できたか
• 何がまだ分からないか

という判断の根拠です。

後から自分が読み返したときにも、同じところで迷った人が検索から来たときにも、完成物だけより役に立つ記録になります。

そのために、このブログを続けます。