BloggerのデザインをAIと1時間で調整した記録

ある日、試しにはてなブログに記事を投稿し、そのURLをXに貼ってみた。すると、投稿にサムネイル画像がきちんと表示された。Bloggerではこれが表示されず、長い間そのままにしていた。ふたつを並べて見ると、印象の差は小さくなかった。

「やはりBloggerは古いのだろうか」と考えかけたところで、ふと思い当たった。これはHTMLの設定を変えれば解決できるのではないか、と。

HTMLに手を出さずにきた理由

1990年代の学生時代、HTMLでホームページを作っていたことがある。だからHTMLが何かは分かっている。ただ、凝ったデザインのページを作るには相当な手間がかかることも、当時の経験からよく知っていた。それ以来、デザインまわりには自分では手を出さない、というのが習慣になっていた。

考えが変わったきっかけは、最近のバイブコーディングの体験だった。AIにコードを任せてみると、自分では書けないようなものが短時間で出てくる。コーディングはAIに任せられるという実感が、HTMLに対する心理的なハードルも一緒に下げてくれた。それで、Bloggerのテーマの手直しにも取りかかる気になった。

実際にやったこと

作業の流れは単純だった。AIに現在のHTMLファイルを渡し、変えてほしい点を言葉で伝える。出力されたファイルをBloggerに貼り付け、ブラウザで表示を確認する。気になる点があれば、またAIに伝える。この繰り返しだ。

指示は、たとえば次のようなものだった。

「フォントや行間をnoteのように読みやすくしてほしい」
「画像のボーダーと影を消してフラットな見た目にしてほしい」
「Xにシェアしたときにアイキャッチ画像が出るようにしてほしい」

HTMLの知識は特に必要なかった。どんな見た目にしたいかを伝えるだけで、自分でコードを書くことは一度もなかった。

結果として、HTMLファイルの改良版を保存した回数は6回。かかった時間は1時間ほどだった（図1）。

図1　同じ記事の表示比較。左（Blogger標準）は行間1.4・フォント12px。右（note風デザイン）はAIとの対話1時間で調整した結果で、行間1.9・フォント16px。

時間がかかったのはモバイル表示だった

全体としては順調だったが、一箇所だけ時間を取られたのがモバイル表示だ。

スマートフォンから見ると、h2よりh3のほうが大きく表示され、見出しのサイズが逆転していた。リンクの下線も表示されない。PCでの表示とはかなり様子が違っていた。

AIと一緒にCSSを修正し、!importantを付けて上書きも試したが、変化がなかった。原因は、Bloggerがモバイル向けに独自のテンプレートを別途配信していることだった。URLに?m=1が付くと、書き換えたCSSが反映されない仕組みになっていたのだ。

解決方法は単純で、Bloggerの管理画面でモバイルテーマの設定を「デスクトップを表示」に切り替えるだけだった。この設定ひとつで、問題はすべて解消した。

ただ、そこに辿り着くまでには少し遠回りをした。AIは「モバイル設定のギアアイコンを押してください」と案内してくれたのだが、そのギアアイコンは現在のBloggerのUIには存在しなかった。AIも私も、設定画面の現状を正確には把握できていなかったことになる。

あとから思えば、スクリーンショットを貼って「この画面にはギアアイコンがありません」と伝えていれば、もっと早く解決できたはずだ。画面の状況を面倒がらずに共有すること。AIと作業するうえでの、地味だが実用的な教訓だった。

乗り換えを考える前に

noteやはてなブログへの乗り換えを考えている理由が「デザインの古さ」だけなら、その前に一度試してみる価値はあると思う。

フォント、行間、文字色、画像のスタイル、Xカードの設定。この程度の調整であれば、AIに任せることで1時間ほどで済む。これまでBloggerに書き溜めてきた記事も、そのまま残せる。

もちろん、noteのコミュニティ機能や記事の販売が目的なら話は別だ。プラットフォームを移す理由には、デザイン以外のものもある。

ただ、見た目だけが理由なら、まずAIに「noteのような見た目にしてほしい」と伝えてみてはどうだろうか。私の場合は、思っていたよりも手軽に済んだ。

---

個人情報を送らずに生成AIを使う——ブラウザだけで動くマスキングツール「ふせじ」を作りました

生成AIを業務に使う場面はずいぶん増えてきましたが、入力するテキストに個人情報が含まれるとき、その扱いにはまだ迷いが残ります。氏名やメールアドレス、所属部署の書かれた文書を、そのままクラウド型のAIに送ってよいものかどうか。大学や研究機関、企業の現場では、こうした戸惑いの声をよく耳にします。

そうした場面で少しでも安心して使えるように、ブラウザの中だけで動く個人情報マスキングツール「ふせじ」を作り、無償で公開しました。

https://fuseji.jp

---

既存ツールを調べてみて

個人情報のマスキングを扱うツールそのものは、すでにいくつか存在します。ただ、実際に調べてみると、個人や小規模な組織が気軽に使えるものは意外と見当たりませんでした。

企業向けのしっかりしたツールは月額契約が前提で、しかもサーバー側で処理する仕組みになっています。無償で試せるデモサービスもありましたが、そちらはマスキングしたい個人情報を、いったん外部のサーバーに送る作りになっていました。個人情報を守るために個人情報を送る、という形になってしまっているわけです。

もう一つ、技術的に気になった点があります。既存のツールの多くは、複数の人物をまとめて同じ記号（●●）に置き換えてしまうため、生成AIに渡した段階で人間関係や文脈が失われてしまいます。誰が誰に何を伝えたのか——本来はその構造こそがAIに読み取ってほしい情報の中心にあるはずなのですが、そこが抜け落ちてしまうのです。

---

設計の基本方針

「ふせじ」を作るうえで一番大事にしたのは、データが外に出ないことを、仕組みそのもので保証するという点です。

ツールはHTMLファイル1つで完結していて、サーバーとのやり取りは一切発生しません。Google Fontsのような外部リソースの読み込みも省いてあるので、ネットワークにつながっていない環境でも動きます。「データを送信しない」と述べる以上、ソースコードを公開して誰でも中身を確かめられるようにしておくのが筋だろうと考え、GitHubでオープンソースとして公開しています。

https://github.com/TadashiNakai/fuseji

---

主な機能

番号付きラベルによる文脈の保持

氏名・法人名・部署名・メールアドレス・電話番号・住所といった個人情報を、種別と番号を組み合わせたラベル（{姓名1}、{学校法人1}、{部1} など）に置き換えます。同じ人物・同じ情報には必ず同じ番号を割り当てるので、置き換えたあとのテキストからでも、生成AIは人間関係や組織の構造、文脈をきちんと読み取ることができます。

たとえば、次のような変換になります。

【変換前】
差出人: 布施 譲治 <j.fuse@fuseji.jp>
宛先: 鈴木 花子 <h.suzuki@fuseji.jp>
件名: 例のプロジェクトの進捗について

鈴木さん
先日の細胞抽出液の精製の件だけど、ついに逆翻訳酵素の単離に成功したみたいだね。

【変換後】
差出人: {姓名1} <{メールアドレス1}>
宛先: {姓名2} <{メールアドレス2}>
件名: 例のプロジェクトの進捗について

{姓2}さん
先日の細胞抽出液の精製の件だけど、ついに{伏字1}の単離に成功したみたいだね。

「逆翻訳酵素」のような未発表の研究情報は、「伏字追加」機能で手動登録して {伏字1} として保護できます。（ちなみに「逆翻訳酵素」は、本記事のデモ用にこしらえた架空の物質名です。生物学に詳しい方はどうかご容赦ください。）カテゴリ名を指定すれば、{未発表物質1} のように意味の伝わるラベルにすることもできます。

日本語に特化した自動検出

日本語の氏名判定は難しいとよく言われます。「ふせじ」では、いくつかの手法を組み合わせることで、実用に足る精度を目指しました。

• メールヘッダー（差出人・宛先・CC）からの氏名抽出
• 敬称（様・先生・教授・部長など）や職位からの検出
• スペース入りの氏名（鈴　木　花　子）への対応
• 3文字以上の姓（佐々木・長谷川・武者小路など）の辞書処理
• ローマ字表記の氏名（括弧内や署名ブロック）の検出

法人名は種別ごと（学校法人・株式会社・医療法人など）に見分けて、{学校法人1}、{株式会社1} のように区別します。部署名・学科名・学部名・大学名も自動で候補として挙げるので、内容を確認し、不要なものを削ってからマスキングを実行できます。

逆変換機能

個人的には、これが「ふせじ」の要になる機能だと思っています。

マスキング済みのテキストを生成AIに入力すると、返ってくる出力にも {姓名1} のようなラベルがそのまま残っています。この出力を「逆変換」機能に貼り付けると、対応リスト（ラベルと原文の対応表）を参照して、元の実名へ一括で戻すことができます。

【AIの出力（ラベル入り）】
{大学1} {学部1} {学科1}の{姓1}研究室に所属する {姓名1} より、
{姓名2}（{姓2}さん）へ向けた業務連絡です。
目標としていた「{伏字1}」の単離に成功した旨が報告されています。

【逆変換後】
政令都市大学 生命科学部 分子生化学科の布施研究室に所属する 布施 譲治 より、
鈴木 花子（鈴木さん）へ向けた業務連絡です。
目標としていた「逆翻訳酵素」の単離に成功した旨が報告されています。

対応リストはJSON形式でダウンロードして保存できるので、日を改めて別のセッションで同じ文書を扱うときにも復元できます。TSV形式（タブ区切りテキスト）の読み込みにも対応しているため、スプレッドシートで管理している対応表をそのまま使うこともできます。

「マスキングして送る → AIから受け取る → 元に戻す」という一連の流れが、すべてブラウザの中で完結します（図1）。

図1　「ふせじ」の実行画面。左側の原文（個人情報を含む）が、右側でラベルに置き換えられます。下部の逆変換パネルでは、生成AIの出力に残ったラベルを、元の実名や情報へ一括で戻せます。処理はすべてブラウザ内で完結します。

---

操作の流れ

基本的な使い方は、3つのステップで済みます。

1. マスキングしたいテキストを左側に貼り付ける
2. ⚡自動判定ボタンを押す（候補が一覧で表示されます）
3. マスキング実行ボタンを押す

不要な候補は✕で消してから実行できます。自動判定で拾いきれなかった固有名詞は、手動の伏字追加機能で補えます。操作の詳しい手順については、図を交えて別の記事で説明する予定です。

---

今後の課題

正規表現を軸にした検出にはどうしても限界があり、文脈によっては誤検出も起こります。そのため現状は、「広めに拾っておいて、目視で確認しながら削っていく」という使い方を前提に設計しています。形態素解析（GiNZA など）を組み込めば精度は上がりますが、ブラウザ単体で動かすという方針とのあいだで折り合いをつける必要があります。

また、いまのところ日本語に特化しているため、英語混じりの文書への対応は部分的なものにとどまっています。

---

まとめ

「ふせじ」は、個人情報の保護と生成AIの活用をどう両立させるか、という現場の実務的な悩みに応えたくて作りました。大学や研究機関、自治体、企業などの現場で、誰かの役に立つことがあれば嬉しく思います。

フィードバックや不具合の報告は、GitHub Issues か X（@TadashiNakai）までお寄せください。

• 公開サイト：https://fuseji.jp
• 繋がらない時の予備サイト：https://fuseji.nakaix.workers.dev/
• GitHub：https://github.com/TadashiNakai/fuseji
• より手軽な使い方の紹介：https://nakaix.hatenablog.com/entry/2026/03/29/165437

---

26年前に自作したPerlのCGIツールを、生成AIでブラウザ向けに作り直した話

2026年になって、26年前に自分で書いたPerl製のCGIプログラムを、あらためて動かしてみた。といっても、自分でコードを書き直したわけではない。生成AIに移植を任せただけで、手を動かした時間は数分ほどだった。

---

2000年のWebと、研究者の「もったいない」

当時の私は、SPring-8（兵庫県にある大型放射光施設。図1）でタンパク質のX線結晶構造解析に取り組んでいた。研究の流れは、おおまかに言えばこうなる。

まず、目的のタンパク質の遺伝子を単離し、大腸菌に大量生産させる。それを精製して結晶にし、SPring-8の強力なX線ビームに当てて構造を決定する。この一連の作業の入り口で欠かせなかったのが、コドン使用頻度（Codon Usage）の確認だった。

生物種によって「好みのコドン」は違う。ヒトの遺伝子をそのまま大腸菌に導入しても、大腸菌が苦手とするコドンが多ければ、タンパク質の発現量は大きく落ちてしまう。どのコドンが何回使われているかを事前に調べ、必要なら配列を最適化する。地味ではあるが、実験の成否を左右する工程だった。

この手の配列解析では、当時Genetyx（ジェネティクス）が定番のソフトだった。ただ、研究費を圧迫するほど高価で、しかも自分が実際に使うのはごく一部の機能だけだ。それなら必要な機能だけ自分で作ればいい、というのは、少なくとも当時の私にとってはごく自然な発想だった。

きっかけをくれたのは同僚の一言だった。「私も使いたい」と言われて、ふと思いついた。当時は趣味で自宅のWebサーバーを公開していたので、どうせなら誰でも使えるようにしてみよう、と。こうしてできたのがDNACNVだ（図2）。DNA配列をアミノ酸配列に変換し、コドン使用頻度を表示するだけのWebツールで、Perlで書いたCGIスクリプトとHTMLフォームの2ファイルで動いていた。

画面は白黒のテキスト表示だった。いま見ればそっけないが、当時としてはごく普通のつくりだ。色をつけることもできたはずだが、機能さえ動けばそれでよかった。

図1. SPring-8の蓄積リング棟。中央の小山は三原栗山。 撮影：Artorius / CC BY-SA 3.0 / Wikimedia Commons

---

26年後の「そういえば」

それから四半世紀が過ぎた。ここ数年、私は生成AIを研究や執筆に積極的に使うようになっていた。最初はChatGPT、続いてGeminiを主に使うようになったが、比較のためにClaudeも試し始めた。バイブコーディングといえばこれ、という印象があったので、まずは定番のテトリスでも作らせてみることにした。

ここで少し意外だったことがある。返ってきたのが、Pythonではなくてブラウザで動くHTMLだったのだ。

なんとなくPythonで返ってくるものと思い込んでいたのだが、Claudeが生成したのはHTMLとJavaScriptで動くゲームだった。サーバーも特別な実行環境もいらない。HTMLファイルをダブルクリックするだけで、そのままテトリスが遊べる。

それを見ているうちに、記憶の隅にあったあのCGIツールのことを思い出した。あのPerlのプログラムも、HTMLに移植できるのではないか、と。

PerlのCGIはサーバー側で計算してブラウザに結果を返す仕組みだが、DNAからアミノ酸への変換は、突き詰めれば純粋な文字列処理だ。サーバーがなくても、計算はすべてブラウザ内のJavaScriptで完結できるはずだった。しかも、当時作ったHTMLフォームとCGIスクリプトが、幸いにも手元に残っていた。

図2. オリジナルのDNACNV（2000年版）。白黒のテキストベースで質素な見た目だが、機能は現在と同じ。PerlのCGIスクリプトとHTMLフォームの2ファイルで動いていた。

---

実際にやってみた

Claudeに渡したのは、2つのファイルだけだ。

• index.html（当時のフォーム画面）
• dnacnv.cgi（Perlのロジック本体）

そして「これを、サーバーなしで動くHTML1ファイルに移植してほしい」と伝えた。頼んだのは、それだけである。

Claudeはまずcgiファイルを読んでロジックを把握し、遺伝暗号表（コドンとアミノ酸の対応）から相補鎖への変換、3フレーム翻訳、コドン使用頻度の集計まで、各サブルーチンをJavaScriptに書き直していった。

結果は、最初の一回でそのまま動いた。エラーは一度も出なかった。

動作確認には、lacZ遺伝子（大腸菌のβ-ガラクトシダーゼをコードする、それなりの長さの配列）の逆相補鎖を入力してみた。問題なく動いた。

出来上がった画面を見て、少しおかしくなった。26年前の白黒テキストに対して、今回の画面はダークテーマにカラフルなグラデーション、モノスペースフォント、アニメーション付きのボタンと、なかなか凝った見た目だったからだ（図3）。デザインについては何も注文していないのに、Claudeが勝手に現代風に仕上げてきた。これはこれで気に入っている。

図3. バイブコーディングで生まれ変わったDNACNV（2026年版）。ダークテーマ、カラーグラデーション、モダンなUIに。機能はオリジナルを忠実に再現しつつ、ブラウザだけで動作する。

---

研究者として一番大きかった気づき

今回のことで一番印象に残ったのは、「移植できた」こと自体ではない。「サーバーなしでWebに公開できる」という点だった。

2000年代に個人がWebツールを公開しようとすれば、まずサーバーが必要だった。自宅サーバーを立てるか、レンタルサーバーを借りるか、大学や研究所のサーバーを使わせてもらうか。CGIを動かすなら実行環境の管理もついて回る。それなりの手間とコストがかかる作業だった。

HTMLとJavaScriptだけで動くツールなら、こうした制約はほとんど消える。GitHubのPages機能でも、ほかの静的ホスティングでも、無料で世界に公開できる。

これは研究者にとって、思いのほか大きな意味を持つ。

たとえば先日、ゲノム編集の研究で、標的となる配列を検索するプログラムをC言語で書いた。今のところ手元でしか動かせないが、これをJavaScriptに移してHTMLとして公開すれば、論文を発表するときに「こちらのURLで実際に試せます」と添えられる。

再現性や透明性が重視される今の科学において、これは単なる便利な付録にとどまらない。研究そのものの信頼性を支える一部になり得ると思う。

バイブコーディングは、趣味や時短の話というより、研究インフラの一部になりつつある。最近はそんなふうに感じている。

---

おわりに

振り返ってみると、今回自分がやったことはごく単純だ。古いファイルを2つ渡して、「サーバーなしで動くHTMLにして」と頼んだだけである。

プログラミングの知識はあるに越したことはないが、「何をしたいか」を言葉で説明できれば、とりあえず動くものが手に入る。そういう時代になったのだと思う。

2000年代初頭のWebには、個人が手作りしたツールが世界中の研究者の役に立つ、という空気があった。商用ソフトが高すぎるなら自分で作ればいい、というエネルギーに満ちていた。その精神は今でも有効だと思うし、実現するためのハードルは当時よりずっと低い。

もし手元に眠っている自作スクリプトがあれば、一度AIに「HTMLにして」と頼んでみてほしい。案外あっさり動くはずだ。

---

今回復活したDNACNVは、こちらで実際に試すことができます： https://tools.nakaix.com/dnacnv/

DNA配列（FASTA形式でも可）をペーストして「Analyze Sequence」を押すだけです。インストール不要、ブラウザだけで動きます。

（おまけ）バイブコーディングの練習として最初に作ったテトリスも、こちらで遊べます（音が出ます。ご注意ください）： https://tools.nakaix.com/tetris/

---

科研費即時OA義務化への実務的な備え：無料で済ませるミニマム対応フロー

2026年度に採択される科研費から、学術論文とその根拠データの「即時オープンアクセス（OA）化」が義務付けられます。

以前のブログ記事（生成AI時代のオープンアクセス戦略）にも書いた通り、私がOAに関心を持った出発点は、「HTML形式で公開しておかないと、生成AIの調査対象に入りにくいのではないか」という問題意識でした。そのためAI向けのアウトリーチとして独自のHTMLリポジトリを構築したのですが、それとは別に、今回は「科研費の即時OA義務化」という制度面での対応も必要になります。もちろんルールは満たしたいのですが、国の方針を文字通りなぞるだけでは、現場の研究はなかなか回りません。

この記事では、2026年度に科研費に採択された研究者に向けて、調べてみると「実はそれほど大変ではない」とわかる現実的な対応策を共有します。私自身も手探りの部分が残っているので、より詳しい方がいれば、ぜひご指摘いただければ幸いです。

制度を読み解く中で感じた疑問と不安

ルールの詳細を確認していく過程で、率直に言っていくつか腑に落ちない点や、実務上の不安を感じました。

まず、情報の即時公開をそこまで重視するのであれば、プレプリントの公開こそ推奨・義務化するのが筋ではないか、という疑問です。プレプリントには触れないまま、査読付き論文の即時公開だけを求める設計には、やや一貫性を欠く印象を受けました。

実務上の不安として大きいのは、出版社のエンバーゴ（一定期間の公開制限）規定との衝突です。科研費のルールを優先するあまりエンバーゴ期間中に公開してしまえば、出版社との契約違反となり、違約金などのトラブルに発展するおそれがあります。

かといって、合法的に即時OAを実現するために「ゴールドOA」を選べば、雑誌によっては数十万円規模の論文掲載料（APC）が必要になります。基盤C程度の予算規模では、年間の研究費の大半がAPCに消えてしまうことも十分あり得ます。できるだけ費用をかけず、かつ契約上も問題のない形でこの制度に対応する方法が必要でした。

「Zenodoで要件を満たせる」という気づき

当初、私は「所属機関のリポジトリで公開しなければならない」と思い込んでいました。

前回の記事では、「AIに研究を認知させるという観点では、ZenodoにPDFを置くだけでは不十分だ」と書きました。しかし今回は、「科研費のルールという事務的な要件を満たす」という別の観点からシステムの仕様を調べていくうちに、重要な事実に行き当たりました。

必ずしも所属機関のリポジトリにこだわる必要はなく、制度上の要件を満たすだけであれば、これまで使った経験のある「Zenodo」で問題ない、ということです。JSPSの公式ページにZenodoという固有名詞が明記されているわけではありませんが、要件とされている「NII Research Data Cloudで検索可能となる情報基盤（KAKENデータベースへの入力による連携）」という条件は、DOIを発行できるZenodoで満たすことができます。

AI向けのフルテキスト公開は自分のHTMLリポジトリで行うとして、制度対応という目的に限れば「Zenodoで十分」というのが、私の辿り着いた結論です。

補足：JxivやResearchmapとの比較

なお、JSPSの公式ページでは、所属機関にリポジトリがない場合の代替手段として、JSTが運営する「Jxiv（ジェイカイブ）」への言及があります。Jxivは「プレプリントサーバー」と紹介されていますが、実際には査読済みの著者最終稿の登録も認められているため、論文の公開先としてルール上の問題はありません。

また、「普段業績を管理しているResearchmapに直接アップロードできれば一番楽なのに」と感じる方もいるでしょう。実際、Researchmap側でも2026年度に向けて、エンバーゴの解禁日設定など「即時OA対応のシステム改修」が進められているという情報があります。

ただし、現状のResearchmapには「研究者1人あたり1GB」という容量制限があります。将来的には改善されるかもしれませんが、今回の制度では論文PDFだけでなく、容量が大きくなりがちな「根拠データ」もあわせて公開・管理する必要があります。実用性と確実性を考えると、容量を気にせず一元管理できるZenodoを使うのが、現時点では最も現実的な選択肢だと考えています。

合法・無料・最小限で済ませる「ミニマム対応フロー」

高額なAPCを支払わず、エンバーゴのある非OA誌で論文を発表する場合の、Zenodoを使った最小限の実務手順は次の通りです。

1. 出版時の対応（データの公開）

まず、該当する「根拠データ」のみをZenodoに登録します。アクセス権を「Open Access（即時公開）」に設定して公開し、データのDOI（DOI-A）を取得します。

2. 出版時の対応（論文PDFのエンバーゴ設定）

次に、別のレコードを新規作成し、査読済みの著者最終稿（ポストプリント）を登録します。ここでアクセス権を「Embargoed Access」とし、出版社のエンバーゴが明ける年月日を指定します。あわせて、メタデータの「Related works」項目に先ほどのDOI-Aを入力し、データと論文をリンクさせます。これで論文側のDOI（DOI-B）を取得します。

3. 年度末の報告（例外理由の申告）

科研費のシステムで成果を報告する際には、取得したDOIを入力し、即時公開できない例外理由として「出版社のエンバーゴ規定のため」と記載して提出します。

エンバーゴ期間が過ぎれば、Zenodoに登録したポストプリントは自動的に公開されます。バージョンアップなどの追加作業は必要ありません。

お金も時間も最低限で済ませるために

これから初めて論文を出す学生や若手教員の方には、こう伝えたいと思います。

本当にインパクトが高く、費用に見合う価値があると判断できる雑誌であれば、そこに研究費を使う選択も十分あり得ます。ただ、日々の研究遂行に必要な資金を、出版コストのために無理に割く必要はありません。お金も時間も最低限で済ませる工夫を、早い段階で身につけておくことをおすすめします。

最後に残る課題は、「根拠データの公開」の実際です。論文のPDFだけでなく根拠データまで即時公開が義務付けられることについて、どこまでのデータが要求されるのかは、現時点では正直なところ未知数です。制度上は「投稿先ジャーナルの規定で公表が求められるデータ」とされていますが、実際にどのような生データやファイルをどこまで準備すべきかは、次に出版する際に改めて調べ、このブログでも紹介する予定です。

---

参考資料・リンク

• オープンアクセス｜科学研究費助成事業（科研費）｜日本学術振興会
• Jxiv（ジェイカイブ）
• Zenodo
• researchmap
• 筆者の過去記事：生成AI時代のオープンアクセス戦略：独自ドメインと個人HTMLリポジトリ

VTuber教員の投稿から思い出した、20年前のアカデミアの空気

今日、X（旧Twitter）で、大学教員として働きながらVTuberとしても活動されている方の投稿を目にした。「動画編集ができるようになったおかげで助成金に採択された」という内容で、その明るい報告を読みながら、私はふと古い記憶を思い出していた。

20年以上前、当時東京大学の助手だった池谷裕二先生が、一般向け書籍の出版やメディア出演について周囲の研究者からたしなめられた経緯を、自身のWebサイトに書いていたという記憶だ。

アウトリーチ活動が広く推奨される現在からは想像しにくいかもしれないが、当時のアカデミアには、一般向けの発信を「本業の邪魔」「余計なこと」とみなす空気が確かにあった。あの文章をもう一度読みたくなった私は、Wayback Machineなども使いながらしばらく探し回った。すると、当時の個人サイトは消えたわけではなく、古いディレクトリの中に今もそのまま残っていることがわかった（実際のページ：http://gaya.jp/media/what_is_science.htm）。

20年ぶりに再読したその文章は、記憶していた以上に切実なものだった。

池谷先生はそこで、「なにより研究が好きである」「テレビや本の執筆の大半は自分ではやっていない」「活動は早朝・夜・休日のみに行っている」と、いくつもの但し書きを重ねながら、自分の立ち位置を丁寧に説明していた。それは弁明といってよいほどのものだった。

今も変わらない危機感と「同業者の目」

現在では、アウトリーチ活動は科研費の申請書でも評価される項目になり、メディアで発信することへのハードルは大きく下がった。それでも、池谷先生の「私は研究中心の生活を大切にしている」という言葉は、今も変わらず重要だと私は考えている。

アウトリーチ活動の方が生活の中心になってしまえば、それは本末転倒だろう。終身雇用の職にあれば定年まで身分を維持することはできるかもしれないが、研究者として幸せな生活は送れないように思う。私自身は幸い、現在は終身雇用の教授という立場にある。それでも、あの文章に流れていた危機感は、20年経った今も他人事とは思えない。

振り返れば、私も20代の若手時代から独自ドメインを持っていたが、そこで積極的に発信することはほとんどなかった。当時は「教育や研究で手が回らないからだ」と思っていたが、今なら別の理由も見えてくる。そこには「同業者の目」という意識が、確かに働いていたのだ。

学生時代に読んだ筒井康隆の『文学部唯野教授』を思い出す。小説家としての活動を学内に知られまいと、本名を伏せて立ち回る唯野教授の姿は、誇張されてはいても、決して絵空事ではない。

実際、私はXやこのブログで、氏名をローマ字表記で通している。海外の研究者と英語論文のやり取りをするうえでの利便性という実際的な理由もある。ただその根底には、漢字の本名をそのままネット上に出すことを避けたいという、一種の自己防衛が働いている気がしてならない。

つい最近も、このブログに科研費に採択されたというタイトルの記事を書いた。しかし、私よりはるかに大型の予算を獲得している同業者の顔が思い浮かび、気恥ずかしくなって、Xのタイムラインには流さずブログに置いたままにしている。これもまた、同業者の目を意識してのことだ。

AIブログという新しい試みと、変わらない心理

そんな私がいま、ブログの執筆に生成AIを全面的に取り入れるという実験をしている。

「AIの利用が面白く、実験として楽しんでいる」というのは本当だ。ただ、この一連の取り組みを通して、自分でも意外な「本音」に気づかされた。

私がAIを使う理由の一つは、「AIで効率化しているので、記事の執筆に自分の時間はほとんど使っておらず、研究時間は削られていません」と言えるようにしておくこと——つまり、かつての池谷先生と同じ種類の「言い訳」を用意しておくことなのだ。

このブログの中で、科研費を取得していることや論文をきちんと書いていることを折に触れて記しているのも、同じ理由による。一流誌に筆頭著者や責任著者として論文を発表し続けられるような圧倒的な業績でもない限り、研究者は「本業をおろそかにしていない」ということを、周囲に、そして自分自身に示し続けなければならないのだろう。

個人のHTMLサイトからVTuber、そしてAIを使ったブログへと、発信の手段は変わり、社会の受け止め方も変わった。一見本業と関係のなさそうな活動が、研究に還元される時代にもなった。

それでも、「Publish or Perish（出版か、さもなくば消え去るか）」という言葉が示すように、研究者の心理と、この世界の基本的なルールは、それほど変わっていないのかもしれない。新しい発信の形を試しながらも、「なにより研究が好きである」という原点だけは、見失わずにいたいと思う。

CPU非対応の中古PCをWindows 11 25H2へ――生成AIに相談しながら進めた手動アップデートの記録

中古PCを選ぶとき、多くの方はメモリやストレージの容量、そして価格とのバランスを見て判断されると思います。私も約1年前、スペックと価格のバランスに納得して一台の中古PC（Core i5-6500、メモリ16GB）を購入しました。動作は快適で、日々の作業にも特に不満はありませんでした。ところがある日、ふとシステムの状態を確認したところ、思わぬ問題を抱えていることに気づきました。

この記事では、OSのサポートが切れていた古いPCを、生成AIに相談しながら最新のWindows 11へアップデートした経緯をまとめます。

気づけばサポート終了、原因はCPUの世代

きっかけは、PCのWindows 11のバージョンが「22H2」のままになっていることに気づいたことでした。調べてみると、22H2のサポートはすでに終了しており、セキュリティ更新プログラムが提供されない状態になっていました。Windows Updateを確認しても、新しいバージョンへのアップデートは一向に表示されません。

原因は、搭載されているCPU（第6世代 Core i5）が、Windows 11の公式システム要件を満たしていないことでした。要件を満たさないPCには、大型アップデートが自動では配信されない仕組みになっているのです。

セキュリティ更新が受けられないままインターネットに接続し続けるのは避けたいところです。かといって、動作自体には何の不満もないPCを手放すのももったいない。そんな板挟みの状態で、しばらく考え込みました。

生成AIに現状を相談してみる

新しいPCへの買い替えも頭をよぎりましたが、その前に一度、生成AIにPCのスペックを伝えて、現状の分析と取り得る対策を尋ねてみることにしました。

CPUが要件を満たしていない以上、アップデートは難しいだろう。そう考えていた私に返ってきたのは、「技術的には、手動でアップデートすることは可能です」という回答でした。レジストリを編集してCPUチェックを回避し、ISOファイルから手動でアップデートするという手順です。もちろんMicrosoftの動作保証外で、将来的に不具合が出るリスクも伴う、自己責任の作業になります。

ただ、私には割り切れる事情がありました。本業の研究ではUnix環境での計算も行うため、もしアップデートに失敗してWindowsが起動しなくなっても、Linuxを入れて計算専用機として使えばよい、というバックアッププランが立てられたのです。失敗しても行き先があると分かったことで、AIに手順を確認しながらこの作業に取り組んでみることにしました。

AIに確認しながら進めた手動アップデート

実際の作業は、思っていたよりも順調に進みました。

AIが順を追って示してくれる手順に沿って、レジストリエディターで特定の値を書き換え、Microsoftの公式サイトからWindows 11のディスクイメージ（ISO）をダウンロードします。

専門外の私には見慣れない作業もありましたが、疑問が出るたびにAIに質問し、確認しながら進められたのは心強い点でした。やがてインストーラーが起動し、システムの更新が始まりました。何度かの再起動を経て無事にデスクトップが表示され、バージョンを確認すると、最新の「25H2」に更新されていました。

小さなトラブルと、シンプルな解決策

ただ、一つだけ気になる点がありました。Windows 11の便利な機能の一つである、エクスプローラーの「タブ機能」が使えなくなっていたのです。フォルダーを複数開くと、以前のWindowsのように別々のウィンドウが立ち上がってしまいます。

これもAIに状況を伝えて、対処法を相談しました。レジストリの修正やシステムファイルの修復など、いくつかの方法が提案されましたが、最終的に解決につながったのは「エクスプローラーのフォルダーオプションを既定値にリセットする」という最もシンプルな方法でした。

設定をリセットして再起動すると、タブ付きのエクスプローラーが元どおりに使えるようになり、これで最新のWindows環境をきちんと整えることができました。

「調べ方」の選択肢としての生成AI

その後、Windows Updateで新しい更新プログラムがいくつも正常に届いているのを確認して、ようやく一安心しました。このPCをまだしばらく安心して使い続けられそうです。

今回の経験を通して感じたのは、「要件を満たしていないから無理」と思える状況でも、調べてみると選択肢が残っている場合がある、ということです。

いまは、エラーメッセージやPCの状況をそのまま生成AIに伝えれば、解決策の候補を整理して、こちらの知識レベルに合わせて対話形式で説明してくれます。従来の検索とはひと味違う、新しい「調べ方」だと感じました。

もしお手元に「まだ十分使えるのに、サポートの対象から外れてしまった」というPCがあれば、手放す前に一度、生成AIに相談してみる価値はあると思います。動作保証外の作業にはリスクの理解と自己責任の覚悟が必要ですが、それを踏まえたうえでの選択肢の一つとして、検討してみてはいかがでしょうか。

生成AI時代のオープンアクセス実践編：古い論文のWordファイルをHTML化する――Symbolフォント問題とその解決

前回の記事では、独自ドメインを利用して「AIに読ませるための個人HTMLリポジトリ」を構築した経緯を紹介しました。今回はその実践編として、2014年に出版した論文のWordファイルをHTML化する過程で遭遇した問題と、その解決方法についてお話しします。

古いWordファイルに残る「Symbolフォント」の問題

過去の論文をオープンアクセス化しようと古いWordファイルを開いた経験のある方には、覚えのある話かもしれません。

2010年代前半ごろまでのWordファイルでは、ギリシャ文字（α、β、γなど）や特殊記号を入力する際、正規のUnicode文字ではなく、アルファベットの「a, b, g」を入力してからフォントを「Symbol」に変更する、という方法が広く使われていました。

前回の記事で作成した「WordからHTMLへ変換するPythonスクリプト」に2014年の原稿を通してみたところ、まさにこの問題に行き当たりました。変換されたHTMLをブラウザで開くと、本文中にあったはずの「α」や「γ」が、四角い記号や別の文字に置き換わったり、そのまま欠落したりしていたのです。

論文全体を見渡して、文字化けした箇所を一つひとつ正しいUnicodeのギリシャ文字に打ち直していく——最初に頭に浮かんだのは、そうした地道な修正作業でした。

教訓：手動で直す前に、まずAIに相談する

ここで得た教訓を一つ挙げるとすれば、「自動化できる作業は手動でやらない。自動化できるかどうか分からない場合も、まずAIに聞いてみる」ということに尽きます。

私は手作業での修正に取りかかる前に、AIに「古いWordのSymbolフォントが原因で文字化けが起きている。良い対処法はないか」と尋ねてみました。

するとAIは、Symbolフォント特有のプライベート領域の文字コード（U+F000番台）を正しいUnicodeに一括置換する処理をスクリプトに追加する、という方法を提案し、そのままPythonのコードを書き換えてくれました。あわせて、変換漏れがないかをスキャンして警告を出すチェック機能も加えてくれました。

改訂されたスクリプトを実行すると、数秒ですべてのギリシャ文字や記号が正しく修復されたHTMLが生成されました。当初想定していた手作業での修正は、結局まったく必要ありませんでした。

図表のマークアップを整えて、AIに正確に伝える

文字化けの問題が解決した後は、検索エンジンに適切に文書の構造（図表を含む）が伝わるようにするための調整を行いました。

Wordから変換した直後のHTMLでは、図表が「単なる画像」や「段落の羅列」として出力されることがあります。人間の目には見出しや図表として認識できても、AIにとっては構造の分かりにくい状態です。

そこで、ブログ（Blogger）の編集画面上で、次のようなひと手間を加えます。

• 図（Figure）： <figure>タグで画像を囲み、その説明文を<figcaption>タグでくくる。
• 表（Table）： 画像として貼り付けるのではなく、テキストデータの<table>タグとして記述し、タイトルは<caption>、見出し行は<th>を使う。

こうしておくと、「ここからここまでが図表のセットで、この文章がその説明文である」という構造（セマンティクス）を、AIに推測させることなく正確に伝えられます。

過去の論文に、新しい読者との接点を

なぜ10年前の論文をわざわざHTML化するのか。

手動での文献検索が主流だった時代には、引用数がそれなりにあり、関連分野の専門家には知られている論文であっても、オープンアクセスになっていない（PDFの壁の向こうにある）限り、AIを使った検索を多用する新しい読者層には届きにくくなっていくのではないか、と考えているからです。

眠ったままになりがちな過去のデータでも、AIが確実に読み取れるHTMLという形に変換してWeb上に公開し直すことで、異分野の研究者や新しい世代の読者と出会える可能性が広がります。

独自ドメインを取得する必要は必ずしもありません。Bloggerなどの無料ブログサービスを使えば、こうした「個人リポジトリ」は誰でも手軽に始められます。もしお手元のPCに眠っているWordファイルがあれば、AIの力を借りてHTML化を試してみてはいかがでしょうか。

---

※注意：論文をセルフアーカイブ（著者最終稿の公開）する際は、出版社ごとに著作権や公開可能時期（エンバーゴ）の規定が異なります。実践される際は各ジャーナルのポリシーを必ずご確認ください。著作権のクリアランスに関する話題は、機会があれば別の記事で取り上げたいと思います。

精製の腕が上がるほど、結晶は消えていった――十年越しに解けた謎

構造生物学の研究には、小さな謎解きを積み重ねていくようなところがあります。そしてときどき、その謎が思いがけない結末を用意していることもあります。

先日、共同研究者から一通のメールが届きました。長いあいだ一緒に苦労し、私も構造決定の一部を分担していた「ある酵素」の結晶構造が、SAD（単波長異常分散法）でようやく解けた、という報告です。ただ、その後に少し残念な話が続いていました。

苦労の末に得られた美しい結晶の正体は、目的の酵素ではなく、精製の途中で紛れ込んだ別のタンパク質――いわゆるコンタミ（不純物）だった、というのです。

この分野では時々耳にする話ではあります。ただ、メールを読みながら、私はただ同情するのとは別に、学生の頃から十年以上ずっと心に引っかかっていた出来事を思い出していました。

少しずつ消えていった結晶

話は1990年代、私がまだ学生だった頃にさかのぼります。当時の私は、ある好熱菌の酵素の結晶化と構造解析に取り組んでいました。

この酵素の精製条件と結晶化条件は、すでに研究室の先輩が見つけていました。私が最初に試したときも問題なく再現でき、「自分の腕が先輩に劣っているわけではなさそうだ」と、ひとまず胸をなでおろしたのを覚えています。

ところが、そこから実験は妙な方向に進んでいきます。タンパク質を精製し直すたびに、結晶が出たり出なかったりするようになったのです。今になって振り返ると、少し皮肉な事実に気づきます。精製の腕が上がって純度が高くなるほど、かえって結晶は出にくくなっていきました。そして最後には、ハンギングドロップの液滴から、結晶は完全に姿を消してしまいました。

運よく手元に残っていたX線回折データも、どこか腑に落ちないものでした。双晶（twin）を判定してみると、むしろ「普通以上に双晶ではない」という妙な結果が出ます。ネイティブパターソン図には大きなピークがあり、偽並進（pseudo-translation）があることは明らかでした。空間群は C2 なのか、それとも R32 なのか。分子置換で素直に解けそうなデータのはずなのに、どう試しても解けません。

結局、その構造は解けないまま、時間だけが過ぎていきました。もっとも、並行して進めていた他の酵素の解析はうまくいっていたので、この一件が致命傷になることはなく、無事に学位を取って大学院を修了できました。それでも、心のどこかには小さな棘のようなものが残りました。

十年後にわかったこと

それから十年以上が過ぎた、ある日のことです。その頃の私は別の研究手法を主に使っていて、構造解析からはしばらく離れていました。ただ、そろそろ解析を再開する予定があり、最新の解析プログラムを立ち上げて準備をしているところでした。

動作確認も兼ねて、昔のあの好熱菌の酵素のネイティブデータと、水銀誘導体のデータを引っ張り出してきました。最新版の解析ソフト（autoSHARP）に読ませてSIR（重原子同型置換法）を走らせてみると、拍子抜けするほどあっさりと位相が決まってしまったのです。主鎖も、大部分が自動でトレースされました。

ついに解けた。そう思ったのも束の間でした。組み上がった主鎖は、本来の標的であるはずの酵素の予測モデルと、まったく合いません。

不思議に思って、得られた主鎖構造を立体構造データベースのDALI Serverに投げて検索してみました。

表示された結果を見て、私は思わず「なんと」と声を漏らしていました。

そこにあったのは、大腸菌由来の inorganic pyrophosphatase（無機ピロホスファターゼ）。発現の宿主に使っていた、大腸菌のタンパク質でした。「まあ、大腸菌を使ったのだから、あり得ない話ではないな」と、自分でも意外なほどすんなり受け入れていました。

ここで、ようやく点と点がつながりました。なぜ、先輩の条件を再現できた後になって、精製の腕が上がるほど結晶が出なくなったのか。答えは単純です。私がカバーガラスの下の液滴で大事に育てていたのは目的の酵素ではなく、ごく微量に混ざっていた大腸菌のコンタミだったからです。精製がうまくなり、不純物をきれいに取り除けるようになった結果、皮肉なことに「結晶の元」を自分の手で捨てていた、というわけです。

同じ罠にはまった研究者たち

改めて論文を調べてみると、この大腸菌の inorganic pyrophosphatase が、なかなか厄介な相手であることがわかりました。精製したタンパク質のなかに痕跡程度しか含まれていなくても、本来の目的タンパク質より先に、きれいに結晶化してしまうのです。

同じように騙された研究者は、世界中にいました。あるグループは別のタンパク質だと思い込んで論文を発表してしまい、後になって「実は大腸菌のコンタミでした」と訂正（Erratum）を出していました。また別のグループは、私と同じように空間群 C2 で悩み抜いた末、PDB（タンパク質構造データバンク）に「SERENDIPITY IN PROTEIN CRYSTALLIZATION（タンパク質結晶化におけるセレンディピティ）」という、少し自嘲のこもったタイトルでデータを登録していました。

謎が解けた後、私は当時の恩師や研究室の先輩に、「あの結晶、実は大腸菌のコンタミでした」と報告して回りました。

論文にはならない謎解きの記録として

研究者というのは因果なもので、長く追いかけていた仕組み――なぜ分子置換で解けなかったのか――がわかってしまうと、結果がどうであれ、それだけで心の底からすっきりしてしまいます。謎そのものが解けたことには、とても満足しています。

ただ、相手が「よく知られたコンタミ」である以上、そこに新しさはなく、学術論文として発表することはできません。真相がわかってすっきりした気持ちと、形に残せない徒労感。その宙ぶらりんな気持ちの行き場として、せめてここに書き残し、本来なら闇に葬られていたはずのデータの供養にしたいと思います。

読者のみなさんの周りにも、研究に限らず、「ずっと理由のわからなかった出来事が、ある日思いがけない形で、それも少し笑える形で腑に落ちた」というような経験はないでしょうか。もしそんな話があれば、よければこっそり教えてください。

令和8年度科研費に採択されました――申請までの準備を振り返って

これまで当ブログでは、文献整理ツールの紹介や、生成AI時代のオープンアクセスへの向き合い方など、研究を効率化し発信するための話題を中心に書いてきました。今回は少し趣向を変えて、研究者にとって避けて通れない研究費の獲得、なかでも科研費（科学研究費助成事業）の申請について、私自身の経験をもとに書いてみたいと思います。

先日、研究代表者として応募していた令和8年度科研費の新規採択通知を受け取りました。

日本学術振興会 科学研究費助成事業 基盤研究(C) 2026年4月 - 2029年3月
（令和8年度新規採択。課題名や共同研究者などの詳細は researchmap にて公開しています）

現在の大学に着任してから、研究代表者として科研費に申請したのは今回で2回目で、幸いどちらも採択していただくことができました。ただ、これは出せば必ず通るという話ではまったくありません。むしろ、難しいと判断した年には申請を見送るという選択を重ねてきた結果でもあります。

この記事では、これから科研費に初めて挑戦する若手研究者や大学院生、あるいは申請を迷っている方に向けて、私が今回の申請までにどのような準備をしてきたのかを振り返ってみたいと思います。

1. 申請を見送った1年と、成果の取りまとめ

実は昨年度（令和7年度向け）の公募では、私は申請を見送りました。理由は明確で、前回の科研費で得られた研究成果を、まだ論文として十分に発表できていなかったためです。

当初3年計画で採択されていた科研費を1年延長し、その期間を成果の取りまとめに充てました。その結果、2025年の1年間で、以下の成果をいずれも筆頭かつ責任著者として発表することができました。

• 中堅の国際誌での原著論文 2報
• 日本語の総説論文 1報
• 学会発表 1件

科研費の審査では、この研究者は計画を確実に実行できるか、という点が重視されます。どれほど魅力的な計画書を書いても、直近の業績が伴っていなければ説得力は弱くなってしまいます。まず論文を出し、そのうえで申請する。当たり前のことかもしれませんが、この順序を守ったことが、今回の採択につながった最も大きな要因だったと考えています。

2. AI技術は実績とあわせて示す

今回の研究計画には、2024年のノーベル化学賞でも注目された「AlphaFold」や「ProteinMPNN」といった、タンパク質の構造予測・デザインのためのAI技術を組み込んでいます。

ただ、こうした話題の技術を計画書に並べるだけでは意味がありません。大切なのはAIを使うこと自体ではなく、自分の研究課題を解決するためにそれをどう活用するかです。私の場合、2025年に発表した論文や学会発表の時点で、すでにこれらのツールを用いた成果を示すことができていました。実際に使って成果を出している手法で次の課題に取り組む、という流れを自然に示せたことが、計画の実現可能性の評価につながったのだと思います。

3. 共同研究の体制

研究は一人で完結するものではありません。今回の申請では、これまでに複数の共同研究の実績がある先生に、研究分担者として参画していただきました。

それぞれの専門性や知見の蓄積に加えて、すでに機能している研究チームがあることは、この体制なら研究を着実に進められるだろう、という審査上の判断材料にもなります。若手の方には、日頃から学会などで交流を重ね、いざというときに協力し合える関係を築いておくことをお勧めします。

4. 審査する側を経験して

もう一つ、今回の申請に役立ったと感じているのは、2025年に科研費以外の研究費助成プログラムで審査員（ピアレビュー）を務める機会をいただいたことです。

限られた時間で何十件もの申請書を読み込むという経験を通じて、忙しい審査員にどう書けば伝わるのか、図をどこに配置すれば要点がすぐに伝わるのか、といった読み手の視点を具体的に持てるようになりました。この経験は、今回の計画書を仕上げるうえで大きな助けになりました。もし審査側に回る機会があれば、相応の労力はかかりますが、引き受けてみる価値は十分にあると思います。必ず自分の申請書の執筆に活きてきます。

おわりに

科研費は、出さなければ採択されることはありません。一方で、準備が整わないまま急いで出すよりも、まず手元の実験データを論文としてまとめ、確かな実績を整えてから申請するという選択が有効な場合もあると感じています。

この記事が、これから科研費に挑戦する若手研究者や大学院生の皆さん、そして日々の業務に追われて申請をためらっている方々にとって、少しでも参考になれば幸いです。

4月からは大学の組織運営に関わる新しい仕事も始まり、いっそう慌ただしい日々になりそうですが、研究室の学生たちとともに、この新しいプロジェクトを楽しみながら進めていきたいと思います。

健康管理だけだったApple Watchを、日々の決済に使ってみた記録

Apple Watchを持ってはいるものの、歩数や心拍数、睡眠の記録といった健康管理にしか使っていない。そういう方は案外多いのではないかと思います。私自身、長い間そうでした。

ところが先日、財布を持ち歩かない身軽な生活に憧れたのをきっかけに、長年使っていたクレジットカードを見直し、あわせてApple Watchで決済できる環境を整えました。

先に書いてしまうと、最初の設定や手続きにはそれなりの手間がかかりました。ただ、それを終えてしまえば日常はずいぶん快適になります。この記事では、私の体験をもとに、Apple Watchの「お財布化」と、その前提となるクレジットカードの見直しについてまとめます。

昔のゴールドカードを、なんとなく使い続けていた

今回まず着手したのが、クレジットカードの見直しです。

私は20年以上も前に作ったゴールドカードをそのまま使い続けていました。ところが最近の事情を調べてみると、いまはナンバーレス（NL）タイプのゴールドカードが主流になっていて、還元率が高いうえに、一定の条件を満たせば年会費が実質永年無料になる仕組みまで用意されていることを知りました。

この条件達成を「100万円修行」と呼んで、目標に向けて決済を集約する方もいるそうです。ただ、私の場合は少し事情が違いました。生活費や各種支払いをすでにメインのカードに集約していたため、毎年ごく自然に100万円以上を使っていたのです。実際、カードを切り替えて3ヶ月ほど経った現時点で、すでに25万円ほどを特に意識することなく決済しています。

つまり私は、こうしたカードの存在を知らなかったばかりに、本来なら払わずに済んだ旧ゴールドカードの年会費を、毎年律儀に払い続けていたことになります。

もちろん、旧ゴールドカードが一方的に劣っているわけではありません。定期的に上質な情報誌が届いたり、海外旅行保険の補償上限が高かったりと、従来型ならではの手厚さは確かにあります。ただ、情報誌はほとんど読まず、海外旅行の頻度もそれほど高くない、という私のような生活であれば、年会費が実質無料で還元率も高いNLカードの方が合理的です。自分が本当に使っているサービスは何かを把握したうえでカードを選ぶことが大切だと、あらためて感じました。

いちばんの手間は、引き落とし先の変更手続き

新しいカードを発行したあとに待っていたのが、各種引き落とし先のカード番号変更です。

電気、ガス、新聞、そして子供の学習塾。過去に登録した支払い先をすべて洗い出し、一つずつ手続きしていく作業は、正直なところかなり面倒でした。

カード会社側で支払い情報が自動的に引き継がれる「洗い替え」という仕組みもあるようですが、すべての支払い先が対象になるわけではありません。引き落としエラーを防ぐには、きちんと切り替わったかどうかを自分で確認していく、地道な作業がどうしても必要になります。

今回の切り替え全体を通して、ここが一番の山場でした。逆に言えば、ここさえ越えてしまえば、あとは楽になる一方です。

Apple Watchでの「二通りの決済」を使い分ける

設定を終えてApple Watchを財布代わりに使い始めてみると、想像していた以上に便利でした。スマートフォンをポケットから出す必要すらなく、手首だけで支払いが完結します。

実際に使ってみて特に良かったのが、場面に応じた決済手段の使い分けです。

1. かざすだけで支払う（交通系IC）

SuicaやICOCAといった交通系ICカードをApple Watchに入れておくと、駅の改札はもちろん、街中の自動販売機や、券売機で支払うタイプの10分カット専門店などでも使えます。ボタン操作なしに手首をかざすだけで支払いが終わるので、こうした細かい場面ほどありがたみを感じます。

2. サイドボタンのダブルクリックで支払う（Visaのタッチ決済など）

コンビニやカフェなど、クレジットカードのタッチ決済に対応したお店では、Apple Watchのサイドボタンをダブルクリックしてカードを呼び出します。財布を探す手間がなくなるうえ、お店によっては高いポイント還元を受けられるので、この一手間をかける価値は十分にあります。

まとめ

クレジットカードの見直しと、Apple Watchのお財布化。設定や手続きには確かに手間がかかりますが、一度済ませてしまえば、日々の支払いにまつわる小さなストレスがずいぶん減ります。

もし腕のApple Watchが健康管理ツールのままになっているなら、まずはクレジットカードの見直しから始めてみてはいかがでしょうか。地味な作業の先に、思った以上に身軽な毎日が待っています。

ブルースクリーンで見捨てかけたPCを、1.3万円で復活させた話

研究にせよ教育にせよ、いまやPCなしでは仕事にならない。ところが、自分の専門から外れた「PCそのもののハードウェア的なトラブル」に直面すると、私を含め、途端に腰が引けてしまう人は多いのではないだろうか。

数ヶ月前、研究室で使っていたHPのデスクトップPCが、起動して数分するとブルースクリーンになり、勝手に再起動を繰り返すようになった。幸い、大事な研究データや授業資料はOneDriveやDropboxに同期してあったので、実害はない。とりあえず隣にあった少し遅いサブ機に作業を移し、問題のPCはそのまま部屋の隅に置きっぱなしになっていた。

メーカーの修理窓口に連絡して発送する手間を思うと気が重いし、かといって同等のPCを買い直せば、いまの時代10万〜20万円は覚悟しなければならない。もう年数も経っているし、これはもう諦めるしかないか……。そう思いかけていたとき、ふと「面倒なことは、とりあえずAIに聞いてみるか」と思い立った。これが、今回の一件の始まりだった。

AIの「目」が本当の原因を見抜いた

エラーメッセージは一瞬で消えてしまうので、スマホで動画を長回しして、ブルースクリーンの瞬間を撮っておいた。その画像を生成AIに投げて、「原因は何が考えられる？」と聞いてみる。

AIは画像の中の「Stop code: 0xc0000218」という文字列をすぐに読み取り、これはレジストリファイルの破損、つまりストレージ（保存場所）が物理的に寿命を迎えたか故障している可能性が高い、と筋道立てて指摘してきた。

そこで私はPCのサイドパネルを開け、中にあった1TBのハードディスク（HDD）を取り外して、その型番を意気揚々とAIに伝えた。これで原因を取り除けたはずだ、と思っていた。

ところが、返ってきた答えは予想外だった。
「それはデータ用のHDDです。起動用のOSが入っている『M.2 SSD』が、PC内部の別の場所にあるはずです」

言われるままにもう一度中を覗き込んでも、ケーブルでつながった分かりやすい箱型の部品は他に見当たらない。半信半疑のまま、マザーボード周りの写真を撮って、もう一度AIにアップロードした。するとAIは、CPUファンのすぐ脇に張り付いた、ガムほどの大きさの薄い基板を指して「これです」と答えた。しかも、けっして鮮明とは言えない写真から、「SK hynix製の256GB NVMe SSD」という型番まで正確に言い当ててきたのだ。

専門外の人間なら見落としてしまう小さな部品を、画像認識AIがあっさり見つけ出す。これには素直に驚かされた。

パーツ選びと、思わぬアナログな落とし穴

原因の部品さえ分かれば、あとは交換するだけだ。AIの助言に従って、交換用のM.2 SSDを探し始めた。

ここで思い知らされたのが、いま（2026年初頭）は世界的な半導体需要のあおりでSSDの値段がひどく高騰している、という市場の現実だった。名前も聞いたことのない新興メーカーの512GBモデルですら12,000円を超えるという有様の中、AIは相場と製品の耐久性（TLCとQLCの違いなど）を並べて比較してくれた。おかげで、信頼できるハイエンドモデル「WD_BLACK SN7100 1TB」の在庫を、約1.3万円という妙に条件のいい価格で発注できた。

数日後にパーツが届き、いよいよ交換作業に入る。古いSSDを外し、新しいSSDを差し込む。ここまでは順調だった。

ところが、ここで最大の山場が来る。SSDを固定するための極小のネジが指先から滑り落ち、PC筐体の奥、入り組んだ配線の隙間へと消えてしまったのだ。
どんなに優秀なAIでも、現実の空間に落ちたネジまでは探してくれない。結局、懐中電灯を口にくわえ、床に這いつくばってPCを傾けながら、自力でネジを捜索するはめになった。最先端のAIに頼り切っていた直後だけに、この泥臭さがなんともおかしかった。

クリーンインストールと、最後のもうひと山

ネジを無事に救出し、物理的な交換を終えたら、次はWindows 11のクリーンインストールだ。

ここでもいくつか引っかかった。私はMicrosoftアカウントと紐づけないローカルアカウントで使いたかったのだが、最近のWindowsは、インターネットにつながっているとローカルアカウントの作成画面を出さない仕様になっている。これもAIに聞くと、コマンドプロンプトで oobe\bypassnro と打ち込んでネットワーク接続をスキップする方法を、すぐに教えてくれた。

設定を終えてデスクトップは無事に表示されたものの、今度は画面の下のほうが黒い帯になって、一部が映らない。「せっかく直したのに、グラフィックボードまで壊れていたのか」と一瞬ひやりとしたが、AIは「オフラインでインストールしたので、いまは画面表示用の仮ドライバーで動いているだけです。ネットにつなげば直ります」と落ち着いたもの。LANケーブルを挿してWindows Updateをかけると、数分で見慣れた正しい解像度の画面に切り替わった。

まとめ：専門外のトラブルこそ、AIに聞くといい

結局、約1.3万円の出費と数時間のアナログな格闘を経て、放置していたPCは、以前より大容量で高速なSSDを積んだ現役マシンとして復活した。買い替えの費用を思えば、かけた金額に対する見返りは十分すぎるほどだった。

今回いちばん実感したのは、自分で調べるのが億劫な専門外のトラブルでも、とりあえずAIに投げてみれば、解決への道筋が案外あっさり見えてくる、ということだ。

PCトラブルに限った話ではない。「専門知識は要るけれど、一から勉強している時間はもったいない」。そういう場面で、生成AIはかなり優秀な壁打ち相手になり、パーソナルアシスタントにもなってくれる。

毎月払っているAIのサブスク料金も、今回の一件だけで、この先数年ぶんの元は取れた気がしている。もしあなたの部屋にも、原因が分からないまま放置している機材があるなら、一度その写真をAIに見せてみてはどうだろうか。

文想からMendeley、そしてZoteroへ。文献管理ソフト遍歴の話

研究者にとって、文献管理ソフトは思考を預けておく相棒のような存在です。

振り返ると、私の文献管理は学生時代（もう26年以上前になります）に使っていた「文想（Bunso）」から始まりました。当時はまだPDFではなく、紙にコピーした文献が主役の時代です。ファイルを添付する機能こそありませんでしたが、文献ごとに考えたことをメモとして残しやすく、今思ってもよくできたソフトでした。

ただ、OSが新しくなるにつれて文想は動かなくなり、次の相棒に選んだのが初期の「Mendeley Desktop」でした。手元のPCにあるPDFを登録し、論文に合わせてファイル名を自由に付け替えられる。この使い勝手が気に入っていました。

ところが近年のアップデートで、MendeleyはElsevier主導の「Reference Manager」へと半ば強制的に移行してしまいます。ローカルでの自由なファイル管理はできなくなり、PDFはクラウド上の、暗号化された無機質なファイル名の中に閉じ込められてしまいました。個人的にはこれを改悪としか感じられず、長いあいだもやもやを抱えていました。

そんな私が最終的に落ち着いたのが「Zotero」です。AIと相談しながら環境を整えていくうちに、Zoteroは初期Mendeleyの自由度を受け継いでいるだけでなく、あの文想のメモの使い勝手までちゃんと備えていることに気づきました。

今回は、サブスク料金を払わずに容量を気にせず論文を管理し、かつての自由を取り戻すための設定を、ひととおり紹介します。

1. Zoteroで「26年ぶんの良いとこ取り」ができる

Mendeleyがユーザーにファイルを触らせない方向へ進む一方で、Zoteroは開かれた管理を守り続けています。

文想ゆずりのメモ機能

Zoteroは文献ごとに独立したリッチテキストのノートを手軽に追加できます。PDFにマーカーを引くだけでなく、自分の思いつきや覚え書きを文献としっかり結びつけて残せる。この感覚は、まさに文想の延長線上にあります。

初期Mendeleyの自由度（ローカルでのファイル管理）

PDFの実体は、自分の好きな場所（Dropboxなど）に置いておけます。意味不明な英数字の羅列ではなく、「著者_年_タイトル.pdf」のように人間が読めるファイル名で、手元のフォルダにきれいに整理されていきます。

2. 作るシステムの全体像

目指すのは、Zoteroの使い勝手とDropboxの見通しの良さを組み合わせた形です。
Zoteroのサーバーには軽い書誌データとメモだけを無料・無制限で同期し、容量を食うPDFはDropboxにリンクとして預けておく。こうすることで、Zoteroの有料プランを使わずに、どのPCからでも同じファイルにアクセスできる環境ができあがります。

3. 設定のポイントは3つ

今回の構築で肝になったのは、次の3点でした。

①リンクを相対パスにする（Base Directory設定）

Zoteroの詳細設定で「リンク付き添付ファイルの保存先」をDropboxに指定します。これをやっておくと、WindowsとMac、大学と自宅でユーザー名が違っても、リンク切れが起きません。地味ですが、ここがいちばん効きます。

②プラグイン「ZotMoov」

拡張機能のZotMoovを入れます。PDFを放り込むだけで、自動でリネーム、Dropboxへ移動、Zotero内をリンクに書き換え、という一連の処理が一瞬で終わります。

③PMIDからPDFを自動で拾う

ステッキ形のアイコンにPMIDを入れるだけ。大学のネットワーク内であれば、Zoteroが出版社サイトから勝手にPDFを取ってきて、ZotMoovがそれをDropboxへ並べてくれます。

4. 移行はAIを「技術顧問」がわりに

今回の移行が思いのほかスムーズに進んだのは、AIをガイド役にしたおかげです。「古い論文がうまくリンクされない」「続けて登録していたらロボット判定が出てしまった」といった細かいつまずきも、その場で相談しながら解決できたので、長年の悩みが実質わずかな時間で片づきました。

---

結びに代えて

いまのMendeleyに二の足を踏んでいる方、あるいは昔使っていた良質なソフトの使い勝手を懐かしんでいる方へ。Zoteroはもう単なる代替品ではなく、私たちが求めていたものをそのまま形にしたツールだと感じています。

ファイルを自分の手に取り戻し、思ったことを自由に書き込む。その先に待っているのは、研究と思考にただ集中できる、あの頃よりずっと快適なデスクトップです。

生成AI時代のオープンアクセス戦略：独自ドメインと個人HTMLリポジトリ

前回の記事の続きとして、今回は先日立ち上げた自分用の論文リポジトリ（https://repository.nakaix.com/）を題材に、これからの研究発信について書いてみたいと思います。

本題に入る前に、そもそもなぜ自分の名前でドメイン（nakaix.com）なんて取っているのか、という話を少しだけ。

正直に言うと、取得した当初は「研究者としての情報基盤を作るぞ」といった大それた考えがあったわけではありません。自分の名前のドメインを持っていたらちょっと面白いかな、くらいの軽い気持ちで取って、あとはなんとなく維持してきただけです。

ところが、遊び半分で持っていたこの独自ドメインが、生成AIの広がりとともに、思いがけず強力な武器に化けつつあります。

「PDFのままではダメだ」と思い知らされた話

独自ドメインを持ったとして、そこに研究成果をどんな形で置くか。ここが意外と大事でした。

先に結論を書いておくと、いまの時代は論文をオープンアクセス（OA）にするだけでは足りません。生成AIに拾ってもらいやすい形、つまりHTMLでどう置いておくか（いわゆるAI Discoverability）が効いてきます。

これまでの私は、エンバーゴ（公開猶予期間）が明けた著者最終稿（ポストプリント）を、ZenodoのようなリポジトリにPDFで登録して、それで満足していました。人間の読者に届けるだけなら、それで困らなかったからです。

ところがある日、自分の分野の研究動向を生成AIに要約させてみて、思わず声が出そうになりました。

返ってきた要約では、私たちより後に出た別の研究室の論文がしっかり取り上げられている一方で、先にやっていたはずの私たちの仕事はほとんど触れられていなかったのです。調べてみると、理由は拍子抜けするほど単純でした。後発の論文はPubMed Central（PMC）などで全文がWebページ（HTML/XML）として読める状態だったのに対し、私の論文はZenodoにPDFで置いてあるだけだったのです。

生成AIの裏側で動いている検索クローラーは、普通のウェブ検索の範囲だと、ダウンロードが要るPDFの中身まではあまり熱心に読みに行きません。このとき、いくら中身の良い研究でも、AIが読めない形式で放置していれば無いのと同じ扱いになるのだ、と嫌でも思い知らされました。内心、少し悔しくもありました。ブログシステムを使ってHTMLベースの個人リポジトリを作ろうと腹を決めたのは、この一件がきっかけです。

WordからHTMLへの変換は「AI×Python」であっさり片づく

とはいえ、「論文の本文をわざわざブログ用のHTMLに直すなんて面倒だ」と感じる方は多いと思います。私も最初はそう思っていました。

実際、はじめはAIのチャット画面に論文を丸ごと貼り付けて、「HTMLタグをつけて」と頼もうとしました。ところが数万字の論文を一度に処理させようとすると、文字数（トークン）の上限に引っかかって、どうにもうまくいきません。

そこで頼み方を変えました。「Wordファイルを読み込んで、きれいなHTMLと画像フォルダを吐き出すPythonスクリプトを書いて」とお願いしたのです。

これがうまくいきました。AIがあっという間にスクリプトを用意してくれたので、あとは自分のPC（ローカル環境）でそれを走らせるだけ。Wordファイルが数秒でブログ用のHTMLに変わるので、変換の手間はほとんど無くなりました。

「そもそもPythonの環境なんて持っていない」という方でも心配はいりません。いまなら「自分のPCでPythonを動かすにはどうすればいい？」とAIに聞けば、数分で環境構築まで付き合ってくれます。

ブレークスルーはMaterials and Methodsに眠っている

そこまでして論文の全文（フルテキスト）をAIに読ませる意味はどこにあるのか。理由は、研究の細かなノウハウがMaterials and Methods（材料と方法）にこそ詰まっているからです。

昔ながらのキーワード検索では、タイトルやアブストラクト（要旨）に出てくる言葉しか引っかかりません。かといって、関連論文すべての実験手法や条件を人間が隅から隅まで読み込んで、使えるノウハウを拾い上げるのは、現実的とは言えません。

その点、AIなら話は別です。膨大なフルテキストの中から、ある試薬の濃度、酵素の精製条件、ゲノム編集の細かいプロトコルといった記述を拾い出し、離れた情報どうしを結びつけてくれます。

じつは最近、いま進めている実験でまさにこの恩恵にあずかりました。他の人の論文の片隅、それもMaterials and Methodsの一文からAIが見つけてきた情報が、思いがけない突破口になったのです。

おわりに：あなたの研究を、世界のどこかの誰かに届けるために

論文を書いて、ジャーナルに載って、はい終わり、ではありません。

ほんの好奇心で取っただけのドメインでも、いまやそれは自分の研究を世界に届ける発信塔になります。そこに、実験手法の細かな条件やDiscussionでの踏み込んだ考察といった中身を、AIが正確に噛み砕けるHTMLの形で置いておく。ブログシステムを使えば、サイトマップ経由で検索サイトやAIのインデックスにもきちんと登録されます。

そうしておけば、世界のどこかの誰かがAI相手に壁打ちをしているそのとき、あなたの研究が思わぬ形で引っぱり出され、新しいアイデアの呼び水になるかもしれません。

生成AIが把握していない情報は、もう存在しないに等しい。そんな時代のアウトリーチのやり方として、独自ドメインと個人用HTMLリポジトリを組み合わせておくことは、研究者なら一度は検討していい次の一手だと思っています。

20年使ったドメイン管理会社をようやく引っ越した話

長く使っているサービスほど、見直すのが億劫になるものです。「まあ動いているし」と自分に言い聞かせているうちに、気づけば何年も経っている。

私にとって、この「nakaix.com」のドメインがまさにそれでした。古いメールを掘り返してみると、運用を始めたのは2002年1月。以来20年以上、ずっと同じ海外の老舗レジストラ（ここではA社と呼びます）に置きっぱなしでした。

その腰の重い私が、先日ようやく管理会社の引っ越し（移管）を済ませました。結論から言えば、年間の維持費はざっと4分の1になり、何よりあの妙な引っかかりのようなストレスから解放されました。せっかくなので、その顛末を書き留めておこうと思います。

気づけば払い続けていた「古参ユーザー税」

A社はインターネット黎明期からある海外の有名どころで、登録した当時は「ここに預けておけば間違いない」という空気がありました。ところが、いつからかその商売のやり方が変わっていったのです。

まず引っかかるのが更新料の高さ。試しに直近5年分（2021〜2025年）の請求を集計してみたら、平均して年に約6,376円も払っていました。今どき「.com」の更新なんて高くても2,000円しない時代に、です。

もっと厄介だったのが画面の作りです。更新手続きを進めると、「プライバシー保護」だの「マルウェア対策」だのといった有料オプションが、いつの間にかカートに入っている。英語のインターフェースということもあって、よく読まずに進めれば余計なものまで買わされる仕掛けです。長年の顧客を大事にするどころか、面倒くさがりや不慣れな人から静かに取り立てる仕組みになっていました。

国内大手に移れば解決……とはいかなかった

A社を離れると決めたはいいものの、次はどこにするか。過去に使ったことのある国内の超大手（B社）が真っ先に頭に浮かびましたが、どうしても気が進みませんでした。

理由は単純で、営業メールの多さと、迷路のような管理画面です。肝心の更新通知が、大量のキャンペーンメールの山に埋もれてしまう。おまけに手続きの途中では、頼んでもいないサーバー契約やオプションのチェックボックスが最初からオンになっている。やっていることはA社と大差ありません。

高い金を払って放置されるか、安い代わりに毎日メールの雨に打たれるか。二択ならどちらも御免です。

AIに相談して見つけた落ち着き先

行き詰まったので、普段から使っているAIに聞いてみました。「安くて、画面が分かりやすくて、商売が誠実な国内の会社はないか」と。

いくつか候補が挙がった中から選んだのは、国内の堅実なサーバー会社が手がけているドメインサービス（C社）でした。入り口だけ安く見せて後から回収する、というよくある釣りがなく、更新費用は国内でも最安の部類で明朗。実際、移管時に請求されたのは1,721円で、これまでのおよそ4分の1です。そして何より、余計な宣伝メールを送りつけてこない。この一点だけでも移る価値がありました。

移管作業と、老舗の最後の「悪あがき」

移管には「Auth Code（移管承認コード）」の取得など、いくつかの手順を踏む必要があります。専門外の英語のメニューを前に途方に暮れるかと思いきや、ここでもAIに助けられました。設定画面のスクリーンショットや届いたメールをそのまま貼り付けて「次はどうすればいい？」と聞いていくだけで、迷わず進められたのです。

ただ、A社は最後まで期待を裏切りませんでした。こちらの申請が済み、あとはA社側が承認ボタンを押すだけの状態になってから、期限ぎりぎりの約1週間、手続きを寝かせ続けたのです。おそらく引き止めのつもりだったのでしょう。待っている間は正直ヤキモキしましたが、「移管完了」の通知が届いた瞬間の晴れやかさは格別でした。

おわりに：固定費は「惰性」で払わない

今回つくづく思ったのは、「20年使っているから」「有名な会社だから」というだけで信用し続けてはいけない、ということです。

ITの世界では、かつての優良サービスがいつの間にかユーザーに不親切な作りに変わっていることが珍しくありません。分かりやすい画面と正直な値付けの会社に移ったことは、浮いたお金以上の価値がありました。

もしドメインの更新料に「こんなに高かったっけ？」と感じたことがあるなら、あるいは毎日のメールにうんざりしているなら、一度管理会社を見直してみることをおすすめします。

※追記
A社〜C社の具体名を知りたい方は、直接ご連絡ください。