カテゴリー別アーカイブ: 仕事

Young woman with glasses studying papers at desk with books, tablet, and lamp at night

水本先生の「生成AIを用いた倫理的・効率的な英語論文執筆」をスキル化しました

はじめに

学期が始まっているっていうのに,まだ春休みモードで今すぐにやらなくてもいいことが捗ってしまっている田村です。

少し前に,Claude CodeやChatGPTを使って論文を丸ごと書くワークフローを紹介するX上の記事をいくつか目にしました。その中には「AIが書いた文章のAI臭さを消すツール(Humanizer)」を強く推奨しているものもあって,正直なところ,うーん…となりました。

AI臭さを「消す」ことが前提になっている時点で,それはもう「AIが書いた論文をAIが書いたとバレないようにする」ワークフローなわけで,なんでそんなものにみんな群がっているのだろうかと。学術倫理的にかなり危ういですよね。

じゃあどうするのか

同僚の水本篤先生が,「生成AIを用いた倫理的・効率的な英語論文執筆」という非常に体系的なWebガイドを公開されています。このガイドは「隠す」のではなく「適切に使って,ちゃんと申告する」という思想で設計されていて,Augmented Competence(AIで拡張できる能力の範囲)の原則や,AI利用の倫理的な判断基準が明確に示されています。

このガイドでは,使えるプロンプトも豊富に掲載されているのですが,論文を書いている作業の中で,あの水本先生のガイドの中のプロンプトを使おうって思っても,探しに行くのに手間取ってしまったり,気づいたら水本先生のXのポストを見に行ってしまって時間を空費してしまう可能性もありますよね。そこで,ガイドの原則をClaude上で自動的に適用できるようにスキル化したら便利じゃないかと思い,水本先生の許可をいただいた上で作りました。

ethical-academic-writing

GitHub: https://github.com/tam07pb915/ethical-academic-writing

日本語版と英語版の両方を用意しています。詳しくはGitHub上のREADMEやそれぞれのマークダウンファイルをお読みいただければと思いますが,簡単にこの記事でも紹介します。

何ができるか

  • 倫理ガードレール:受容能力の範囲内での支援に限定。「自分では書けない表現は使わない」を自動チェック
  • AI生成文で目立ちやすい表現への注意喚起:一律禁止ではなく,不必要な反復を点検
  • 8つの失敗パターン検出:AI丸投げ,架空引用,文体キメラ(文体のツギハギ状態)などを警告
  • 3段階の洗練プロセス:内容の英語化→文体調整→表現の磨き上げ
  • セクション別テンプレート:CARSモデル(Introduction),ムーブ分析(Discussion),APA統計書式(Results)など
  • AI利用申告の自動生成:使用状況に応じた5段階のテンプレート
  • 査読対応:模擬査読,Response to Reviewers,カバーレター支援

何をしないか

  • 本文の丸ごと生成(ユーザーの骨格が必要)
  • 文献・引用・DOIの生成
  • AI検出回避を目的とした書き換え

要するに,AIに「論文を書かせる」のではなく,「自分が書いた論文をAIで診断・洗練する」ために,生成AIに読み込ませる指示書ファイル群です。

使い方

claude.aiのProjectに入れて使うのがおすすめです。論文執筆用のProjectを作って,SKILL.mdをProject Instructionsに貼り,references/のファイルをProject Knowledgeとしてアップロードするだけです。

Claudeの用途がほぼ論文執筆だけの人は,ユーザースキルとしてインストールして全会話に適用してもいいと思います。

私はいつも,Claude Code使おうかなってClaudeに相談すると,「あなたの用途なら全然必要ない。」って言われていまだにclaude.aiとCoworkしか使っていないのですが,Claude Codeの場合は ~/.claude/skills/ にフォルダごとコピーすればOKのようです。

作る過程で面白かったこと

このスキル自体は,水本先生のウェブガイドをソースにしてClaudeに作らせました。ところが,最初のバージョンで参考文献の書誌情報が間違っていました。Kobak et al. (2025) のタイトルが不正確だったり,Mizumoto et al. (2024) のDOIパスの一部を論文タイトルだと誤認していたりという。私が見ていたら,参考文献がなんか怪しそうだなと気づき,調べてみたら誤りだと気づきました。「文献はAIに生成させるな」「DOIは必ず検証しろ」とスキル自身が書いているのに,スキルを作ったAI自身が(というか私がといってもいいんですが)それをやっている。なかなか皮肉な話です。これは他にもありそうだなと思って,ChatGPTにファクトチェックさせたらそっちも著者名を間違えていたので(実在する筆頭著者+架空の共著者という部分捏造型ハルシネーション),最終的にCrossrefで検証して修正しました。

この経験自体が,水本先生のガイドが言っている「AIの出力を無批判に採用しない」「ファクトチェックは人間がやる」の重要性を実証しているなと思って,ちょっとだけ肝が冷えました。最近,論文を書くときに先行研究のレビューでこんなことやってるor言ってる研究ないかなとGeminiのDeep Research使って調べてもらったのですが,自分がよく読んだことのある論文に「XXXX」という直接引用があってこれがまさにあなたが知りたかったことですよね,みたいなレポートを出してきたんですよ。「おまえ自分では(アクセスできないから)ほとんどの論文のアブストしか読めないくせにそんな自信満々に書いてきて胡散臭いぞ」と思って論文の中身を検索したら全然そんなことは書いてありませんでした。ということもありました。Xのおすすめとかは私が興味あることもあって割とAIすげえええみたいなのとか,研究への利用の話も流れてくるのですが,冒頭で私が言及した記事とかもマジでありえん話でしたし,ほんとXは140字でも胡散臭いのたくさんあったのに長文記事は長く書いてある文だけ信憑性がありそうな雰囲気が漂っていて,マジでひどいです。長文記事も長文ポストも,途中まで読んでAI臭がしてだめだってなるの多いですよねほんとに。あれ,なんか脱線して愚痴っぽくなってしまいました。

おわりに

私的には,AIを論文執筆に使うこと自体は止められない流れだと思います。だからこそ,「隠す」方向ではなく「ちゃんと使って申告する」方向でやっていかないといけないなと感じていますし,でもかといってまだまだ試行錯誤の真っ只中でもあるので,あれこれ試しながら,自分にあった方法も使いながらって感じでやってます。ブログ記事も,生成AIに整えてもらうことはあるんですが,それで自分らしさがなくなっちゃっちゃーいやよね,とか思ったりもしました。

そこで,私は自分が2012年からやってるこのブログの全記事をxmlファイルでダウンロードして,それをマークダウンファイルに変換してNotebookLMに読ませて文体の分析をさせました。それをClaudeにスキル化してもらって,最終的に私らしさが失われないようにチェックしてもらうようにしようかなとか思っています。

私はまあ数は多くないですが,生成AI登場以前も論文を書いたことがあるので,それを使って自分の論文のスタイルとかロジックとかの「クセ」をNotebookLMに抽出してもらって,生成AIとやりとりしながら作った文章が,過去の自分の書いた論文とズレがないかをチェックしてもらうみたいなのも同じ発想でできそうですよね。

おわりにとかいって全然終わらせる気がない感じになってしまいましたが,水本先生のガイド(https://langtech.jp/ai-writing/)は本当によくできているので,スキルを使うかどうかに関わらず,一度目を通すことをおすすめします。

なにをゆう たむらゆう。

おしまい。

追記(2026-04-14)

使い方について訂正

上で「claude.aiのProjectに入れて使うのがおすすめです」と書いたのですが,実際にやってみたら全然制御が効きませんでした

Project InstructionsにSKILL.mdを貼って,referenceファイル(プロンプトテンプレート集やチェックリスト)をProject Knowledgeにアップロードする方法だと,Claudeがreferenceファイルを「必要」と判断したときしか読みに行かないので,せっかく作ったテンプレートやチェックリストがまったく参照されないことがありました。

現在の推奨はカスタムスキルとしてのアップロードです。

  1. GitHubからZIPでダウンロード
  2. claude.aiで Settings > カスタマイズ に移動(現行ではコネクタにいくと,カスタマイズへの移動を促されます)
  3. カスタマイズの中の「スキル」を選択
  4. +ボタンでスキルを作成を選択し,
  5. 「スキルをアップロード」を選んでZIPをアップロード

これでスキルのdescriptionに基づいてClaudeが自動判断で読み込むようになります。「論文の英語を直して」とか「査読コメントへの返事を書きたい」みたいな依頼をすると勝手に効きます。効いてないなと思ったり,「ここで呼び出そう!」みたいなタイミングがあったら意図的にスキル呼び出すのもいいと思います。

なお,Claude Codeの場合は ~/.claude/skills/ にフォルダごとコピーすれば,/ethical-academic-writing のようにスラッシュコマンドで明示的に呼び出すこともできます。

文体チェックスキルの話

「おわりに」で書いた,ブログの文体分析→自分らしさのチェックの話ですが,実際にスキルとして実装しました(こちらは個人用で非公開)。

やったことは以下のとおりです。

  • ブログの全記事XMLをマークダウンに変換してNotebookLMに読ませ,文体の特徴を抽出
  • 論文の方も,自分の単著・筆頭論文のPDFをNotebookLMに読ませて,語彙・文構造・論理展開の3層で特徴を抽出
  • 抽出結果をプロファイルとしてまとめて,ドラフト完成時にプロファイルとの乖離をチェックするスキルを作成

論文用のプロファイルでは,たとえば「mightをmayより好む」「Looking at Table X, … でデータを参照する癖がある」「Limitationsは率直に認めた上で”In spite of these limitations, the study does add to…”で締める」みたいな自分のクセが抽出されていて,ちょっと面白かったです。AIで推敲した後にこういう個性が消えていないかを点検する,という使い方をしています。

ポイントは,プロファイルは「正解」ではなく「ベースライン」だということです。乖離が見つかったとしても,それが意図的な改善なのか,AIに引きずられた無自覚な変化なのかは自分で判断します。voiceチェックでフラグが立ったら即修正しないとけないというわけではなくて,あくまで自分では見逃してしまっていた箇所がないかということを確認するためのツールです。


更新履歴

  • 2026-04-13(初版公開):スキルの紹介,使い方(Project方式),ファクトチェックの失敗談
  • 2026-04-14(追記):使い方をProject方式からカスタムスキル(ZIPアップロード)に変更(Project方式ではreferenceファイルが参照されない問題が判明)。文体チェックスキルの実装報告

論文ページからワンクリックでTeamsに共有できるChrome拡張を作った(というかほぼClaudeに作ってもらった)

はじめに

矢野雅貴さん(@masayano_)がXで「Claudeにお願いしたら,ジャーナル論文のウェブサイトでクリックするだけで,タイトルや簡単な概要・解説を研究室のDiscordに投稿するアドオン作れた」と投稿されていて,これめちゃくちゃ便利やんと思いました。

私はゼミではDiscordではなくTeamsを使っているので,Teamsで同じことができないかと試してみたところ,できました。Gemini APIの無料枠を使えば,論文の日本語解説まで自動生成して一緒に投稿できます。とはいえ,ウェブで取ってこれる情報に依存するので,論文全体を読んでの解説ができるものとできないものに分かれるのかなとは思います。「解説」は今の段階ではアブストの日本語訳って感じですね。

コードはGitHubに公開しています。

https://github.com/tam07pb915/paper-to-chat

完成イメージ

論文ページで拡張のアイコンをクリックすると,こんな感じのポップアップが出ます。

拡張のポップアップ画面(論文情報が表示された状態)

「投稿する」を押すと,TeamsのチャンネルにGeminiが生成した日本語解説付きで投稿されます。数秒かかりますが,Geminiが解説を生成しているのでしょうがないです。

Teamsに投稿された結果(解説が途中で省略されます)
Teamsに投稿された結果(詳細表示後はこうなります)

仕組み

やっていることはシンプルで,Chrome拡張が論文ページからメタデータ(タイトル,著者,DOIなど)を抽出して,Gemini APIで日本語解説を作って,Power AutomateのWebhook経由でTeamsに投稿する,という流れです。Highwire Press標準の citation_* メタタグに対応しているので,PubMed,Wiley,ScienceDirect,JSTAGE,CiNiiあたりはだいたい動くらしいです(あまりよくわかっていない)。

セットアップ

1. Chrome拡張のインストール

GitHubからZIPをダウンロードして解凍したら,chrome://extensions/ を開いてデベロッパーモードをONにし,「パッケージ化されていない拡張機能を読み込む」から解凍したフォルダを選ぶだけです。インストールできたら,アドレスバー右のパズルアイコンからピン留めしておくと使いやすいです。

2. Power Automateの設定(ここが一番面倒)

ここが一番の沼でした。2025年末にTeamsの旧Incoming Webhook(コネクタ方式)が廃止されていて,「to be retired」と表示されているのに新規追加しようとしてもできないようでした。Power Automate経由にするしかないんですね,今は。これも時間が経つと変わるかもです。

Power Automateにアクセスして,「インスタント クラウド フロー」を作成,トリガーに「Teams Webhook 要求を受信したとき」を選びます。

トリガーの下にアクションを追加して,「チャットまたはチャネルでメッセージを投稿する」を選択。投稿先のチームとチャンネルを設定して,メッセージ欄には fx(式)タブ から triggerBody()?['message'] と入力します。ここは⚡(動的コンテンツ)タブではなくfxタブです。最初そこで詰まりました。

保存したら,トリガーを展開してHTTP URLをコピーします。これがWebhook URLになります。

もう一点ハマったのが認証の話で,トリガーの認証設定が「すべてのユーザー」になっていないと拡張からの投稿がエラーになります。OAuth認証が求められる場合はトリガーの設定で認証を外してください。

あと,Power Automateには「カードを投稿する」(Adaptive Card)というアクションもあるんですが,外部からのJSONに対する制約が厳しくて何度もエラーが出たので,「メッセージを投稿する」のほうを使うのが無難らしいです。

私はブラウザ版Teamsを使っていますが,デスクトップ版でも「…」メニューに「ワークフロー」が表示されなかったので,そういうときはPower Automateに直接アクセスして設定したほうが早いとClaudeに言われてこういうめんどくさいことをやりました。

3. Gemini APIキーの取得(無料,カード不要)

Google AI StudioにGoogleアカウントでログインして,「Create API Key」をクリックするだけです。無料枠が1日1,500リクエストまであるらしく,論文共有に使う分には全く問題ないと思います。

4. 拡張の設定

拡張のアイコン → ⚙ (歯車アイコン)設定を開いて,Webhook URLとGemini APIキーを貼り付けて,「Gemini APIで解説を自動生成」をONにして保存します。解説不要で素早く投稿したい場合はこれをOFFにすれば即投稿されます。

研究室での使い方

これはTeamsの使い方に依存すると思います。みんなが見れるチャンネルに情報共有的な意味合いで論文貼るみたいなことだと,全体のチャンネルに投稿することになるでしょう。私は,自分含めて学生の名前のついた個別のチャンネルを作って,そこに自分の研究の進捗だとかメモだとかそういうのを書き込んでいくという方針でやろうと思っています。私のチャンネルがあるのは,自分が率先して「思考をみんなが見れる場所に投稿していく」というモデルになれればという気持ちです。そういうわけで,私の個人チャンネルに投稿できるような設定にしました。もちろん,院生にも同じ拡張をインストールしてもらって各自のWebhook URLを設定すれば,院生が自分用メモとして自分のチャンネルに投稿できるようになります。文献共有の専用チャンネル作って各自がそのチャンネルのWebhook URLを共有して設定すれば,輪読候補の論文ストックとして扱うみたいなこともできるのかもしれません。「面白い論文見つけたけどそれをとりえあずどこかにストックしておくのが面倒」という摩擦を下げるのが目的なので,そこは運用してみないとわかりません。ちなみに,論文自体はZoteroとNotionDBを連携して学生にはそちらにストックしていくように指導にしようと思っているので,そういう意味では今後やってみて運用方針を変える可能性は大いにありそうです。

おわりに

矢野さんのアイデアはDiscord + Claude APIでしたが,Teamsに合わせてPower Automate経由にして,コスト面からGemini APIに差し替えました。アイデアをシェアしてくださった矢野さんに感謝します。

Chrome拡張を更新(リロード)した後は論文ページもF5で再読み込みしないとcontent scriptが再注入されないので注意です。これも地味に引っかかりました。

コードはGitHubに公開しています。改善提案やPull Requestも歓迎です。

GitHub: https://github.com/tam07pb915/paper-to-chat

なにをゆう たむらゆう

おしまい。

何の役に立つのかは教員が語らなくてもいいのかも

はじめに

学部の講義科目,「何の役に立つの?」と思われるって自分で思い込んでたけど,その問いは学生が自分たちで自分の日々の経験や他の授業で学んだことと関連付けて答えを出そうとしてくれていることを,毎週のリアクションペーパー(以下,リアぺ)を読んでると感じます。
こちらが,「この話はこういう点で役に立つよ」なんて言わなくてもいいのかもしれないなと。

教員と学生が一緒に作る授業

そのことを,教員の責任を放棄してるとか,学生頼みとか考える人ももしかしたらいるのかもしれませんが,私は授業は教員が一方的に学生に知識を授けるものではなくて,教員と学生が一緒に作っていくものだと思っています。そういう意味では,その理想に近いのかなと。

指示しなくても,学生は自然と

しかも,私は学生に,この授業が何の役に立つか考えなさいとか,自分の経験に照らし合わせて考えなさいとか,そういう指示は出していません。そういう指示は出さなくとも,学生は自然と自分がした経験や考えたことと授業で扱ったことを関連づけようとしています。「私が経験したあの出来事は,もしかして今日の授業のこの説明が当てはまるんじゃなかろうか」とか,自分で思考を深めたり,問いを導き出していったり。
もちろん,そういった書き込みの中に,本当は自分で考えていなくて,生成AIで書いたようなことももしかすると含まれているのかもしれないし,それはもうわからないのでなんとも言えません。でも,そうは思えないコメントがたくさんであることは間違いないと自分では思っています。

「学の実化」は学生がもたらすもの

私はずっと,自分が研究していることは現実世界に直接的に役に立たないとか,現実世界の問題を直接的に解決するようなものではないと思っていました。最近,研究と社会との関わりについて考えさせられるポストも目にしました。


少なくとも授業という文脈では,私の所属先である関西大学が掲げる「学の実化」というものは,教員が学生に与えるようなものではなく(そういう場合もあるのでしょうが),むしろ学生の側が主体的に,「私が今学んでいることは,私の生きている人生や,この社会にどう関係しているのだろうか」ということを考えることによってもたらされるのかなと最近は思います。
私の授業はそうやって受けるものなのだということを明示的に指示しなくても,外国語学部の学生が主体的に,そして自然とそのような姿勢で授業を受けてくれていることに,私は感銘を受けています。そして,その事でとても誇らしい気持ちになると同時に,彼らがきっと,それぞれの場所で今も,そしてこれからも輝きをはなってくれるに違いないという確信めいたような気持ちになります。

なにをゆう たむらゆう。

おしまい。

非常勤の話

はじめに

3年目に入った関学と追手門の非常勤,教えてる内容は基本的に同じなので,自分の中であんまり変化がないように感じることがたびたびありました。それが理由で,そろそろ辞めどきかなと思うことが何回かありました。ところが,続けていると毎年毎年新しい学びが自分にもありますし,やっぱり教えてる学生さんが違えば交互作用があって受け止め方だったり,思考の発展していく方向性だったりも違うのでそれが面白いなと思って続けてるところがあるんですよね,というお話。

第二言語習得の授業

追手門の第二言語習得は,フルオンデマンド開講ですので,これまでに一度も学生さんたちに会ったことはありませんし,読むための資料教材ベースで授業を作っています。それでも,学生さんたちも必死に理解しようとしてくれていて,自分のことと引きつけながら色んな内容を咀嚼してくれています。第二言語習得研究の面白さだったり,研究という営みそれ自体に対する理解だったりが伝わっているのが毎回のリアクション・ペーパーから伝わってきます。そらを全部読んで、毎回60ほどのリアクション・ペーパーに全て返事を書いています。フルオンデマンドな分,インタラクティブな要素を唯一もてるのがそこなので。学生さんに刺激をもらって,こちらも毎週頑張ろうと思えています。

もちろん,フルオンデマンドなので,「全然資料を読まずに生成AIにキーワードだけ伝えて文章作ったでしょ」と思ってしまうような,資料に全く関係ないことを書いている人もいます。それ自体は,どういう授業をやっても一定数出てきてしまうものだと思うので諦めているところはあります。

英語科教育法の授業

関学の英語科教育法の非常勤も,当たり前ですが,学生が変われば反応も違うし,どこが「刺さるか」みたいなのも年によって違います。例えば最初の頃は,主にピアフィードバックに対して,「生徒の能力の差があったらうまくいかない」,「できない子は何もフィードバックできなくて,できる子が損する」,みたいな意見が結構あって,そこをときほぐすようにしていました。その次は,「入試があるから」,という入試要因に強く反応する学生が多くいました。そこで,「でも実際には4大進学率自体がそもそも高校生の半分ほどで,さらに大学進学者の中でもいわゆる受験勉強が必要な一般受験が必要な割合はこのくらいで、最近は流れ的に年内入試の割合も増える方向に(主に大学側の都合で)シフトしているよ?それでも入試のために授業はあるべき?」みたいな話をしたり。

この春学期に教えている学生たちは,実践に対する関心が高くて,学習者の立場ではなく,教師の立場でTBLTを体験したいという声が出たので, これまでやったことのなかった模擬授業的なことを取り入れたりもしました。本来は,私の受け持つ科目は理論重視のはずで,実践は他の授業でカバーされていると聞いていたんですけどね。

教師役が学生だと,学習者の立場でタスクをやる学生たちも,タスクそのものに熱中するのはもちろんのこと、同じ学生の立場でありながらも教師役をやる学生たちのパフォーマンスを見ていますし,実際に教師役をやったら気づけたということにもたくさん思考がふくらんでいるように思います。

初めての取り組みだったので,改善のしようはあると思うのですが,今後も継続的にやろうかなという気持ちではいます。実際に教師役を授業の一部でも体験してもらうと,こちら側としても,普段の授業ではみえないような教師としての適性を感じることもあります。

また,実際に教えてみたら自分には無理だと思ったという感想もありました。そういう感想は少し残念ですが,なんていうか,「TBLTは難しい。無理だ」っていう気持ちも理解できます。それはある意味では真理というか,実際に学習者に即興を求めるのであるからこそ,教師の側も即興の能力を求められることは間違いないと思います。ただ,だからTBLT「の方が」難しいみたいに思われてしまうと自分の意図とは違う方に行っているなという気はします。そもそも,授業をやることそれ自体がそんな簡単なはずはないですしね。机間巡視してる中でどうやってフィードバック出すか,どこは説明してどこは説明せずにいくか,早くタスクが終わった学習者を退屈させないためにどうするか,沈黙が続いてるペアにはどんな介入をするか,とかそういうのはTBLT関係なく,英語の授業を成り立たせるために必要なことですからね。方法論に全く関係なく。「そうだとしたら,そもそも英語教師は私には無理だ、こんなことはできない」と思われてしまってもちょっと違うという気もしています。

「英語教師は簡難しくないよ。誰だってなれるよ」なんてことは言いたくないです。専門職ですし,自分の職業にプライドも持ってほしい。でも,なんていうか最初から完璧に何もかもこなせないとやってはいけない仕事でもないわけですよね。むしろ,そういう仕組みにもそもそもなっていないわけですし。私が彼ら・彼女らが教師になってからその成長をサポートできるわけではないので(求められたらそりゃ全力でしますけども),大丈夫だ頑張れっていうのも無責任なんですけどね。

おわりに

最後に脱線しましたけど,今やっている非常勤の授業も,毎授業自分にとって新しい発見があるし,毎学期,その時の受講生にプラスになるような内容を提供できている部分もあるかな思うことができている,というポジティブなお話でした。もちろん,今に満足せずにもっといい授業にしていくための営みは止めることなく続けていきます。

なにをゆう たむらゆう。

おしまい。

ノート探しの旅②:アイデアを書き留める

はじめに

ブログ記事のネタになりそうだなみたいな,そういうパッと浮かんできた思考みたいなのを書き留めておく,そういう目的のために使うノートアプリでNotionが「個人的には」うまく使えないというお話。下のポストに書いたことが端的に言いたいことです。

自分がノートアプリに求めていること

自分がどういうノートアプリを求めているんだろうなと思って書き出してみたら,次のような感じになりました。

  • デバイス間のシームレスな同期
  • ノートをカテゴリ分けできること
  • Markdownが使える
  • ノートを自由に共有できること
  • とにかくメモしておきたいという欲求にダイレクトに答えてくれて、それをあとで整理しやすいこと

最後のとにかくさっとメモしたいというときにNotionっていまいちだなって思うのですよね。その一方で,Evernoteの「スクラッチパッド」はめっちゃ神機能だと個人的には思っています。スマホでもブラウザでも,ホーム画面にどしんと構えていて,そこになんでもとにかく形式だのなんだのとかはとりあえず置いていて思考を書き留められる。バーっと書いたら,あとはそれをノートに変換しておけば,ホーム画面のスクラッチパッドはまた空になる。変換されたノートは変換するときにカテゴリ分けしておいて,授業メモならその授業のノートにいれるし,ブログネタならブログネタのノートにいれるという感じ。スマホでObsidianを使っていない私にとって,こういう使い方のできるノートアプリでの最強はEvernoteです。結構なお値段するし色々すったもんだありましたけど,なんだかんだでもう10年以上使い続けているという愛着もあって気に入っています。あれ,もう全部Evernoteでいいのかな?という気もしますが,階層性をもたせた共有というのはEvernoteにはできません。アカウントがあれば,ノートブック単位で共有ができるし,権限を閲覧のみにすれば,私が思っているような共有ができます。ただ,こういう用途でゼミとかならまだしもそうではない授業で全員にアカウントを作らせるっていうのはちょっと気が引けます。よって,その用途ではNotion一択。

では,アイデアを書き留めるっていう目的でNotionは使えないのか?っていうのをちょっと試行錯誤しました。以下,その手順。

1. Scrachpadというページを用意

まずScrachpadというページを用意して,それをお気に入りにしておきます。そうすると,左側のバーの一番上にそれが表示されるのでアクセスしやすくなりますし,スマホアプリでもそれが上に表示されます。お気に入りにしていると,iPhoneのウィジェットに Notionを入れておけば,アプリを開かなくてもワンタップでそのページを開けます。

2. Scrachpadページにとにかく書く

まっさらなノートにバーっとメモします。

3. テキストを選択してページに変換

そして,そのメモを全選択して,ページに変換をするわけです。そうすると,そのメモが新しい独立したページになって,Scrachpad内にはその新しいページへのリンクができます。最初は箇条書きで書いていて,その箇条書きを全選択してページ変換しようとしたら,その一つ一つが独立したページになってしまって,いやそういうわけじゃねーよとなりました。よって,書き込みを一つの段落にしました。これで大丈夫だ,と。そしてリンク先に飛ぶとそれが….

こんな感じで,書いたやつが全部タイトルにされてしまうんです。いやそういうことじゃねーなー感が満載ですよね。タイトルって最初に考えるんじゃなくて,文章を書いて最後に考えるじゃないですか?だって,メモし始めたときには思考がどこに着地するのかもわからないわけですから。

有料版だと解決する?

もしかすると,有料版にしたらホーム画面を自由にカスタマイズできるようになって,私が求めているEvernoteでいうScrachpadみたいなものが設置できたりするんでしょうか?正直,もしそうなら課金してもいいくらいには考えています。かといってEvernoteを完全に辞められるかどうかはまだわからないのですけどもね(禁断症状)。

なにをゆう たむらゆう。

おしまい。

ノート探しの旅①:書き込めない問題

はじめに

「①」とつけましたが,いくつまで続くかはわからないまま書き始めています。先日,Obsidian publishを使ってみた感想という記事を書きました。その記事内で,次のように書きました。

この状況を考えると,授業関連のメモをそもそもObsidian上で集中的に管理し,それをPublish機能で公開するという運用自体が,私の使い方には合っていないのかもしれません。Notionならこういうことができるんですかね。となると,授業関係のメモは全部Notion使ったほうが良いのかもしれません(識者情報求む)。

すぐに,「識者」の方から情報提供が寄せられました。

直面した問題

その後,Notionを実際に使ってみて,Obsidian Publishingではできなかったような,授業ごとに資料を独立させて,その中に個別のノートへのリンクを貼っておくというようなことができるようになりました。しかしながら,授業でそういった使い方をしようしたその瞬間に,あることに気づきました。

これだと,学生は資料に書き込みしたりハイライトしたりできないな?

アカウントがあって,共有の設定を工夫すれば,もしかすると学生が自分でPDFにエキスポートしたりできるのかもしれません。しかしながら,それでは元の資料との「断絶」を生むことになります。教員側が行った更新は,コピーした学生の資料には反映されないわけなので。

これに対して従来のPDF形式の資料には,学生が自由にハイライトを付けたり,メモを書き込んだりできるという利点があります。多くの学生にとって,この機能は学習過程において必要不可欠なものかもしれません。

Notionのいいところ

私がNotionでの共有に魅力を感じた理由の一つは,Markdownでの資料作成との相性の良さでした。Obsidianでは,PDFへのエクスポートには様々な不便さが伴います。例えば,1ページに収めたい内容が微妙に2ページ目にはみ出してしまい,文字サイズの調整が必要になることがあります。さらに、修正のたびにPDFを作り直してLMSにアップロードし直す必要があるという手間も気になっていました(Notionで書いたものをPDFにしようとすれば同じ問題にぶちあたります)。

Notionのページを直接見てもらえれば,こういった手間を省くことができます。修正が必要になったときにさっと修正して,それが学生側の資料にも反映されます。教員側からすれば,自分が見ている資料と同じものを学生と共有できれば効率的です。しかし,これは教員側の視点であって、学生側からすれば、LMSから外部リンクへの遷移が必要になることは余計な手間に感じられるかもしれないということも考える必要があるかもしれません。

適した資料と適さない資料

書き込み問題に対するtentativeな解決策は,書き込みが必要になるであろうというようなそういうタイプの資料はNotionのリンクを共有するというのは避けるということになるかと思います。逆に,参照型資料や,なにかの指示のような「読んでおくだけ」と考えられるようなものは,積極的にNotionに移行していくことがいいのかな,というのをなんとなく考えています。そうなると,授業の「メイン」となる資料はどうしようかな,というところが悩みどころです。

おわりに

ObsidianからNotionへと移行して,いいところはあったので,そこからObsidianに戻るという選択肢はいまのところありません。ただ,資料共有と階層性の問題は解決できた一方で,書き込み可能性という新たな課題が浮上してきました。資料共有の試行錯誤はまだまだ続きそうです。

ブログのアイデアを書き溜めるという用途でのNotionの利用も試行錯誤しているので,それについてもまた別記事で書こうかと思います。

なにをゆう たむらゆう。

おしまい。

Obsidian publishを使ってみた感想

はじめに

研究や授業関係のノートはObsidianを使っています。ローカルのnoteをウェブ上に公開できる「Obsidian publish」というサービスがあるので,手元の授業資料をウェブに連携させて見て貰うの楽だなと思うことがたまにあるので,試しに使ってみました。使ってみた感想を書きます。一言でいうと,自分が「こういう使い方をしたい」という用途にはあっていないかなという感じです。手軽に情報を公開できるという期待があった一方で,特にノートを公開した際にそれらが意図せず関連付けられてしまう点(Obsidian上の構造がそのまま反映されてしまう点),そしてすべての情報が一つの場所に集約されてしまう点が,ちょっと自分がやりたいことと違うかなと。。

情報の見せ方・見え方

私が問題視しているのは,個人的なノートが公開されることそのものではありません。公開したいノートと公開したくないノートは選べます。そうではなく,公開されたすべてのノートは同じアドレス直下に位置することになるという点です。つまり,例えばある特定の授業を受講している学生にとって,全く関係のない別の授業の資料まで同じ場所から見えてしまうという状況が,どうもしっくりこないのです。そうやって,複数の場所に別々のノート群を公開しようと思えば,その数だけ料金を支払う必要があります。

理想の共有スタイルとObsidian Publishの特性

理想としては,それぞれのノート(この場合は授業資料)を独立したリンクとして個別にシェアし,必要な情報を必要なオーディエンスだけに見せたいと考えています。しかし,Obsidian Publishでは,基本的にすべてのノートが一つの場所にまとめて公開されるため,関連性の薄いノートを異なるオーディエンスに向けて整理して見せたい,といった私の用途には,残念ながらあまり向いていないように感じました。

授業関連の資料を例に挙げると,ある授業の学生に資料を共有したい場合,その学生とは無関係な別の授業の資料まで同じ場所からアクセスできてしまうのは,情報の整理という観点からも,学生の混乱を招く観点からも避けたいところです。特定のノートだけを選択的に,かつ整理された形で公開したいというニーズには,現状のObsidian Publishの仕組みでは応えにくい面があるようです。

Evernoteでもいいのか?

このような,特定の情報を独立して共有したいというニーズに対しては,Evernoteのリンク共有機能の方が適しているかもしれません。しかし,Obsidianの最大の魅力は,普段書き溜めている手元のMarkdownノートをそのまま手軽に公開できる点です。そのためだけにEvernoteにデータを移行するのは,せっかくのObsidianの利便性を損なってしまうため,避けたいところです。

この状況を考えると,授業関連のメモをそもそもObsidian上で集中的に管理し,それをPublish機能で公開するという運用自体が,私の使い方には合っていないのかもしれません。Notionならこういうことができるんですかね。となると,授業関係のメモは全部Notion使ったほうが良いのかもしれません(識者情報求む)。

代替案の模索:bookdown?OneDriveでいい?

Markdownで書いているという利点を活かすなら,私がRを使ったデータサイエンスの授業資料でやっているように,bookdownなどのツールを使ってオンラインに資料を体系的に蓄積していく方法も有効な選択肢にはなるのだと思います(それでもbookdownしたものをウェブにあげる作業がめんどいんですけどね)。

私がObsidian Publishで実現したかったのは,マイナーチェンジが頻繁にありそうで,かつ個々の資料自体の関連性があまりないケースでのノート公開でした。具体的には,「この授業のこの資料を学生に見ておいてほしい」といったマニュアル的なものを,それぞれの授業ごとに複数作成し,対象となる学生に必要なものだけを見せられるようにしたかったのです。

しかし,前述の通りObsidian Publishでは公開場所を複数に分けることができません。関連性のないノートも全てが一つの場所に公開されてしまうため,この点がネックとなりました。Evernoteはノート単位での共有は得意ですが,ノートブック単位での柔軟な共有はできず,複数の資料をまとめて共有するには手間がかかります。

そうなると,現状ではOneDriveなどのクラウドストレージでフォルダごと共有し,そこに資料を整理して格納していく形が,私のイメージしている使い方に最も近いのかもしれません。そうすると,もはや資料は全部Wordで作るってことになりますよねぇ…。

おわりに

Obsidian Publishは非常に手軽に情報を発信できる強力なツールですが,今回のような特定の用途においては,他の方法を検討する必要がありそうです。LMSに資料を全部載せればいいっていうのはそうなんですけど,やはりそうするとローカル上のものをいちいちアップロードすることになるし,毎年マイナーチェンジを繰り返すようなものは毎年過去のものと新しいものが混在化して,よくわからなくなったりするんですよね。Obsidianは気に入っているので,ツールはできればあまり増やしたくない気持ちもあります。悩ましい。

なにをゆう たむらゆう。

おしまい。

学会事務局仕事をちょっと楽に

はじめに

最近,Claudeに「学会事務局業務」というプロジェクトを作って,いろいろな業務を助けてもらっています。Claudeはプロジェクトという単位でチャットをまとめてくれて,そのプロジェクトに特有の指示や情報を与えられるので重宝しています。

よくやっているのは,

  • メールの返信文面を考えてもらう
  • 生HTMLで構築されたウェブサイトのページを更新する(コピーして新しく作り直す作業も含む)
  • ページの英語版を作る(<-半ば勝手にやってる)

一番最後の英語版については,役員表の英語版を作るのが地味に面倒で億劫だったのですが,日本語ページのソースコードを渡したら9割くらいはできていました。所属先の英語名もほぼあっていて,漢字の読み方がちょっと違うくらいでそこは手作業で修正しました(もしかすると間違っているところがあるかもですが)。今回は,「メールテンプレにcsvからの情報を流し込む」という話。

メールテンプレにcsvからの情報を流し込む

私は学会事務局で,学会発表の申し込み後,審査を経て結果を応募者にメールで通知する際に,今まではメールのテンプレだけは作っていました。そのテンプレに応募情報や審査員のコメントなどの情報ちまちまコピペしてメール送る,というようにやっていたんですね。別に件数もそんなに多くないので手作業でもまあいいかみたいな。

ふと,Claudeにこういう作業って楽にならないんですかね?と相談してみたところ,Pythonのコードを作ってくれました。私はPythonは触ったことはあるのですが,自分で実用レベルでは使いこなせないので,Pythonコードを動かすのはちょっとハードルが高いと思っていました。しかし,Claudeはコードの実行まではできません。そこでChatGPTにPythonコードの実行をお願いしたところ,ほとんど私が求めているような形で,申込情報と審査コメントの入ったcsvファイルから自動的にメールを作成してくれました。いやーこれは助かります。多少の微修正は必要でしたが,これまでの作業よりは圧倒的に楽だと感じました。使い回せるし,他の同じようなメール作成にも転用できそうな気がしています。もっと早くやってたらよかったなと今更ながら思っています。

おわりに

なんとなく,こういうことも書いておこうかなと思ったので書きました。

なにをゆう たむらゆう。
おしまい。

Obsidianで「やったことリスト」をつくる

はじめに

私は何年か前から,「やることリスト」や「To Do List」ではなくて,「やったことリスト」をつけるようにしています。

ToDo(やること)リストじゃなくてDone(やったこと)リストをつけよう

2つの記事のうち下のものは10年以上も前に書かれているので,アイデアとして何か目新しいわけではありません。なんでそれやるの?みたいな話の詳細は上の2つの記事をお読みください。私はとにかく,「なにかやった」ということを日々積み重ねていってそれを可視化したい,というのが大きいです。「いや〜今日は何もできなかった」という日でも,ノートを書くために一日を振り返ってみたら,「仕事をしないぞ。休むぞ。」と決めた日以外には絶対に何かやってるんですよね。「あ,何もやってないと思ったけどなんかやってたわ。」と(自己肯定感下がらない)。「てか意外に結構やってない?」と思う日もありますし。一日にやってる仕事の数が多すぎて,こんなリスト書いてる時間がもったいないよと思っちゃう人もいると思いますけど,そういう人は別にこんなことしなくても自己肯定感下がったりしないと思うし必要のないことなので,関係のない話かなと思います。私みたいに,「ああ,私は仕事のできないダメ人間だ」という気持ち(になったりすることがある)人の参考になる可能性があるかもしれないということでこの記事を書いています。ぜひ試してみてください。

さて,この記事では,Obisidanを使って「やったことリスト」を実現する方法を紹介します。

以前はEvernoteでやっていた

リストをObsidianに移行する前は,Evernoteに一つの「やったことリスト」というノートを作って,そこに毎日日付の見出しを作ってからチェックボックスで消していく(あえてチェックボックスにするのが個人的には重要)というようにしていました。このノートはホーム画面にピン留めしておいて,Evernoteを開けば常に見れるようにしていたというわけです。

Evernoteは値上げをどんどんしていて,Evernote離れしている人も増えていますが,私個人としてはWebクリッパー(この用途では10年以上使っています)や紙関係でスキャンしたものの保存先として多用しているので,利用を辞めることはおそらく今後もないと思います。ただ,研究関係のメモをObsidianに移行してからは,Evernoteを開く機会自体が結構減ったんですよね。結果として,Evernoteを開くのが面倒だからリストを作るのも面倒で,さらには毎日日付を自分で書くのも面倒だなと思い始めてしまったのです。

日付書くの面倒問題以外でも,リストにちょっとしたメモを残したりできたら便利だなと思っていました。次はこういうふうにやり方を変えようとか,これの続きを次にやるときはこっからスタートだよとか。そういう余白みたいなのがないんですよね。一つのノートだと。となると,毎日のノートが独立していたほうがいいんです。最近Evernoteでもデイリーノートが作れるのを知ったので,Evernoteでも解消できるかもしれませんが,研究関係のものが常に目に入るようにするためにもObsidianは常時開くようになっていたので,Obsidian上でやったことリストができないかなと思い,実際にやってみたというわけです。

自分が理想としていたリストの作り方

いろんなやり方があると思いますが,私が思い描いていたのは次のような仕組みです。

  1. ワンクリックでデイリーノートを作れる
  2. デイリーノートにはテンプレとしてタスクリストがすでに記入されている
  3. 毎日のデイリーノートが「やったことリスト」という名前の別のノートに自動的にリンクされる(やったことリストからデイリーノートにジャンプできる)
  4. リンクされるのは「リスト部分」だけで,見出しが日付,その下にリスト,という見え方になる
  5. 新しいリストは常に上に追加される

おそらく,1のところはコアプラグインの起動時にデイリーノートを開くという設定をONにすれば,クリックすらせずにデイリーノートが作れると思います。ただし,私の場合は毎日の日記というよりも「仕事」メインなので,仕事をしない日にはデイリーノートを作る必要がありません。むしろそれで作ってしまうと,デイリーノートがあるのに何もやっていない日が逆に可視化されてしまって本来の目的と逆方向にいってしまうのでよくありません。そういうわけで,ワンクリックする手間を設けています。

必要なプラグイン

  • デイリーノート
  • Dataview

多分最小限でこの2つで可能なはずです。まずはプラグインをインストールしましょう。話はそれからです。

ちなみに,私はなぜかコアプラグインの”デイリーノート”ではなく,”Periodic Notes“というコミュニティプラグインを使っています。なんでそうしたのかはもはや忘れました。WeeklyとかMonthlyとかのノートも作れるので汎用性が高いからかもしれません(まだ毎週,毎月とかでノート作って書いたりしてないですけど)。あ,”Calendar“プラグインとの統合があるからかもしれませんね。カレンダービューで日付をクリックするとその日のデイリーノートに飛んでいけるみたいな。もしかしたらコアプラグインのデイリーノートでもできるのかもしれませんけど。まあそれは今回のメインの部分とはあまり関係ないので割愛します。

それから,”Dataview“これが肝です。これがあることで,日々のデイリーノートを「やったことリスト」に蓄積していくことができます。使い方はめちゃくちゃ汎用性が高くて難しいので,私はChatGPTに聞きながら使いました(もっというと,「Obsidianで,デイリーノートが自動で生成され,そこに作られたタスクビューが自動的に別のノートに蓄積されていくっていう仕組みを作りたいです。」ってChatGPTに質問して教えてもらいながらトライ・アンド・エラーを繰り返して最終的に自分が欲しかった形にたどり着きました)。

余談ですが,ChatGPTに教えてもらったときに,Tasksというプラグインをいれるように言われましたが,実際にはこのプラグイン入れなくてもこの目的で利用する分には何ら問題ありません(このプラグイン自体は便利だと思いますが)。私は締切があるようなタスク管理にはMicrosoftのToDoリストを使っているので。

手順1. テンプレファイルを作る

テンプレファイルを作って,保管庫に置いておきましょう。私は保管庫直下にDailyNote_Template.mdというファイル名で下記画像のようなテンプレファイルを作りました。そして,新しいデイリーノートは”DailyNote”というサブフォルダ内に生成されるようになっています。

同じ名前のファイルがあればそのファイルが開かれるようになっているので,同じ日に複数のファイルを生成してしまうということはありません。やったことはTasksのところに記入していって,メモ的なことはNotesに書くという感じになります。

手順2

デイリーノートが生成されるサブフォルダ内に,「やったことリスト」という名前のノートを作ります(もちろん名前はなんでもいい)。そのノート内に次のように記入してください。”DailyNote”というのはノートを引っ張ってくるフォルダの名前ですので,ご自身の環境に合わせてそこは書き換えてください。

```dataviewjs// ページごとのタスクを格納するための空のオブジェクトを初期化
let tasksByPage = {};

// "DailyNote" フォルダ内のすべてのページを取得し、作成時間の降順でソート
let pages = dv.pages('"DailyNote"')
  .sort(p => p.file.ctime, 'desc');

// 各ページを繰り返し処理し、タスクを抽出
for (let page of pages) {
  let tasks = page.file.tasks;

  // ページにタスクが含まれている場合、未完了タスクと完了タスクに分類
  if (tasks?.length > 0) {
    tasksByPage[page.file.path] = {
      page: page,
      incompleteTasks: tasks.where(t => !t.completed),
      completedTasks: tasks.where(t => t.completed)
    };
  }
}

// tasksByPage オブジェクトの各エントリを繰り返し処理してタスクを表示
for (let path in tasksByPage) {
  let { page, incompleteTasks, completedTasks } = tasksByPage[path];

  // 未完了タスクがある場合、それを表示
  if (incompleteTasks.length > 0) {
    dv.taskList(incompleteTasks, { checked: false });
  }

  // 完了タスクがある場合、それを表示
  if (completedTasks.length > 0) {
    dv.taskList(completedTasks, { checked: true });
  }
}

// タスクが見つからなかった場合、メッセージを表示
if (Object.keys(tasksByPage).length === 0) {
  dv.paragraph("No tasks found in the daily notes.");
}```

色々ChatGPTとあれこれやり取りした結果,DataviewJSというのを使うことになりました(プラグインの設定でDataviewJSが使えるようにしてください)。ぶっちゃけ,このコードに実は余剰な部分とかもあるのかもしれませんが,これで機能しているのでとりあえずいいとしています。「やったことリスト」の出力は下記画像のような見た目になります。

私が結構難儀したのは,最新のノートが上に来るように並び替えることと,見出しをファイル名だけにすることです。見出しにファイル名と日付がダブって入ってしまったりして,かなり何回もChatGPTとやり取りした記憶があります。

ちなみに,完了マークと日付が入っているのと入っていないのがありますが,完了マークと日付が入るのはTasksプラグインの仕様です。このプラグインを使うと予測変換の入力がうまくいかないというのと,項目だけ立ててチェックを忘れてしまったときに,本当はその日のうちにやったのに次の日に終わったようにチェックが入ってしまうというのがあって,他のノートのタスクリストとかでもこのプラグインなくても問題ないよな?とさっき確かめたら問題なさそうだったのでアンインストールした結果,今日の分だけ見え方が変わっています。

もうひとつちなみに,22日の次からノートがスカスカになっているのは,コロナに罹患して仕事どころではなかったからですw

何を「やったこと」に含めるか

私個人的には,研究に限らず仕事の範疇に含まれるものは結構細かいものでも含めています。メール返信とかは一度の返信で済むものだったのでそういう書き方していますが,もし何往復もするようなものだったら,「XXXについてメールでやりとり」というような書き方にしています。論文も,「ただ書いた」だけだとどんくらい書いたとかどこを書いたとかがわからないので,できるだけ具体的にするようにしています。大きなタスクの中にサブタスクがある場合は22日の例のようにインデントしています(実際には論文は書き終わっていないけれども親タスクのところもチェックするのがポイント)。論文とか研究とかはまた別にObsidianの中にまとめのTodoリストがあって,ある研究や論文に固有のノートの中のリストが#ToDo/Researchで拾ってこれるようにしていたりします。そことデイリーノートを連携できていたりはまだしないので,重複した内容をデイリーノートに書くこともあるといえばあります。ただ,そもそもこの「やったことリスト」を作って蓄積していく目的というのは,「なんかやったぞ」もっというと,「何もやってなくないぞ」というのを可視化する目的なので,厳密に「やらないといけないこと」(ToDoリスト)と一致していなくてよいと思っています。むしろ,そういうToDoリストにもぶっちゃけのぼりもしないような細々としたタスクをも可視化するののが目的なんです。

おわりに

この記事では,「やったことリスト」をObisidanのデイリーノートとDataviewを使って蓄積・可視化していくということを書きました。ChatGPTに聞けば,もっと多分いろんなカスタマイズできるんじゃないかと思いますので,詳しいことは私に聞かないでください。

なにをゆう たむらゆう。

おしまい。

Shiny Appsで名前列をランダムに並び替えるアプリ

Shiny Appsで遊ぶシリーズ第2弾。第1弾は以下でした。

Shiny Appsでランダムグループ分けアプリ

今回は,もっと単純に,名前の列を入力したらそれをランダムに並び替える,というだけです。発表順をランダムに決めるとか,議事録担当者をランダムに決めるとか,様々な場面でご利用いただけます。

https://yutamura.shinyapps.io/RandomOrder/

なにをゆう たむらゆう。

おしまい。