前回までの連載のあと、2023年秋に『Obsidianで"育てる"最強ノート術』を刊行しました。そして2025年になって、Obsidianが大きく注目を集めています。今回はその背景と理由について解説します。 AIとの連携 ObsidianはノートアプリやPKM（Personal Knowledge Management）ツールとして注目を集めました。主な特徴として、この連載でも解説してきた次のことが挙げられます。 ローカル環境で動作する Markdownで書いたノートをリンクできる 階層型のタグで管理できる プラグインで拡張できる そんな中、2025年になって注目された背景として、「AI（人工知能）との連携」があります。ここでは「生成AIの進化」「RAGとMCPの登場」「AIエージェントの登場」という3つの視点から紹介します。 生成AIの進化 2022年末にChatGPTが公開されて
はじめに 昨今、AI の進化により、様々な分野での応用が進んでいます。特に、自然言語処理(NLP)の分野では、RAG( Retrieval-Augmented Generation)が注目されています。RAG は、情報検索と生成を組み合わせた手法であり、特に大規模言語モデル(LLM)と組み合わせることで、その性能を大幅に向上させることができます。 また、NativeRAG や GraphRAG, AgentRAG などさまざまな RAG のバリエーションが登場しており、これらは特定のユースケースやデータセットに対して最適化されています。 今回は、RAG の基本的な概念から、RAG のプロジェクトの進め方、精度向上の方法に至るまで詳しく解説します。 みなさんの GenAI Application の開発に役立てていただければ幸いです。 本記事は 5 万文字を超える大作となっております。 お時
タスクによっては（もしかすると業務の大部分？）、生成AIにまかせたほうが自分でやるよりはるかに早くて質も高いのは認めざるを得ないところ。 いかにシームレスでマイクロに生成AIを活用できるかが業務効率化の肝になってきますよね。そうなると、日々使いまわすプロンプトの運用術は、重要な基本スキルといえそうです。 本記事では、「プロンプトづくり」「呼び出し」「管理」の3ステップでのプロンプト運用術を提案。テキスト入力効率化ツール「Text Blaze」の活用方法を中心にご紹介していきます。 プロンプトを考えたり呼び出したりがちょっと面倒……と考えている方、生成AIフレンドリーな環境づくりの一環としてぜひ参考にしてみてくださいね！ ステップ1. プロンプトづくりScreenshot: 山田洋路 via Anthropicなにか生成AIに作業させたい……と思い立ったときには、とりあえずAnthropic
米AppleのAI研究者らは10月7日（現地時間）、「GSM-Symbolic: Understanding the Limitations of Mathematical Reasoning in Large Language Models」（LLMにおける数学的推論の限界を理解する）という論文を発表した。 この論文は、LLM（大規模言語モデル）が、本当に人間のように論理的に考えて問題を解けるのか、という疑問を検証している。結論としては、LLMは今のところ、表面的なパターンを真似て答えを出しているだけで、真の推論能力は持っていないと主張している。 研究者らは、これらの問題点を検証するために、「GSM-Symbolic」という新しいテスト方法を開発した。これは、LLMの数学的推論能力を評価するためのベンチマークデータセット「GSM8K」を改良し、問題の表現や数字を柔軟に変えられるようにした
はじめに ソースコードをLLMに読んでもらうとき、単一ファイルだと楽なのですが、GitHubのリポジトリのように複数ファイルから構成されるプロジェクトだと困ってしまいますね。 リポジトリごとLLMに読んでもらえるようにいい感じにテキスト化できると良いですね。そんなソフトがありました。しかも2つ。 両方ともほとんどコンセプトは同じです。特に後者のgenerate-project-summaryは使い方も含めて、自分のやりたいことが、すでに開発者の清水れみおさんが以下の記事にまとめていました。 なので、あんまり書く必要ないのですが、せっかくなのでgpt-repository-loaderの使い方と、出力したファイルの別の活用方法について書いてみたいと思います。 gpt-repository-loaderでリポジトリをテキストに変換 使い方はREADMEに書いてあります。シンプルなソフトなので、
はじめに はじめまして、8月にコネヒトに入社したy.ikenoueです。 突然ですがみなさん、生成AIは使っておりますでしょうか？ ChatGPTやStable Diffusionといった代表的な生成AIの発表から約1年が経過し、そろそろブームも落ち着くかと思っていたのですが、つい先日もOpenAI DevDayにてChatGPTに関する様々なアップデートが発表されるなど、相変わらず目まぐるしい日々が続いていますね。 弊社における生成AIの活用状況はというと、以前に下記の記事にて、Slack上でChatGPTと会話できる環境を社内提供しているという取り組みをご紹介しました。 tech.connehito.com 本日は、上記の社内ツールに新たに追加した「社内文書の参照機能」についてご紹介します。 「社内文書の参照機能」の概要と開発動機 まずは「社内文書の参照機能」の概要と開発にいたった動機
透明性を高める公開ロードマップ 利用者との信頼構築のためにも、現在運営として何を考えているかわかるよう、機能ロードマップもSlackのリスト機能を活用して公開しています。 v0 (Vercel社が提供する生成AIによって画像・自然言語からUIコードを生成するツール)を使ったプロトタイプなどを使い、ここでやり取りすることにより、各部署/グループ会社のAI活用推進者とも連携をとりつつ、個々のステークホルダーとのやり取りが断片化しないように合意形成を進められます。 OpenView Partners （PLGの提唱企業）によるNotionなどの事例 継続的なカスタマイズ開発 私たちのプロジェクトでは、Difyをシングルテナントのまま、全ユーザーが自由な相手を選べるReBAC（関係ベースのアクセス制御）のアプリ共有機能を独自に実装しました。これにより、利用者ごとの組織・利用形態に合わせた柔軟にアプ
はじめに 本記事では、ChatGPT と LangChain の API を使用して、PDF ドキュメントの内容を自然言語で問い合わせる方法を紹介します。 具体的には、PDF ドキュメントに対して自然言語で問い合わせをすると、自然言語で結果が返ってくる、というものです。 ChatGPT と LangChain を使用することで、下記のような複数ステップの仕事を非常に簡単に実行させることができます。 PDF ドキュメントからテキストを抽出して複数に分割する 分割したテキストからテキスト間の関連を表すベクターデータを作成する 作成したベクターデータをベクターストアに格納しておく ChatGPT に外部から与えたベクターストアを使って問い合わせに答えるようにさせる これにより、大量の PDF ファイルを自動的に解析し、必要な情報を素早く抽出できるようになります。 本記事では、ChatGPT と
9/28の #日本CTO協会 さんのイベントで登壇した資料を公開しました。 「ChatGPTの10ヶ月と開発トレンドの現在地」 開発のトレンドの最新情報をざっくり纏めています。 ・Prompt Engineering開発の現在地 ・RAG開発の現在地 ・Plugin開発の現在地 ・GPT-V…
GPT-4oの入力コンテキストは殆ど嘘だということ。 例えば、DRMをクラックした本とかを読ませて「なんて書いてある？」みたいなことを聞いてみると分かるのだが、後半については殆ど無視される。128Kトークンという巨大な入力コンテキストウィンドウを持っていることになっているが、これは殆ど嘘、ごまかしであり、出力を高速化するために「渡されたものの前のほうだけ読んで適当に回答する」ということをやってくる。でもこれについて問題視している人をほとんど見たことがないので、とっくにみんな生成AIには飽きていて使ってないんだと思う。 現実的な対策としては、RAGをがんばるか、あるいはテキストを分割して適切なサイズにしてから渡していって最後にその結果を統合するか。それか「OpenAIさんはそのレベルで信用できないことをやってくる」ということを前提にそもそも使わないか。
どんな人向けの記事？ これからRAGを作ってみたい DifyやLangChainにこだわらず、自分で開発をハンドリングしたい ベクトルDBや埋め込みモデルの選定の勘所をサッと知りたい ここではRAGとは何かのような話題は扱いません。 RAGが、ほぼAI活用の現実的な最適解になりつつある LLMは高度な知的タスクを実行可能である。 そんな理解が世界に広まっていく中で、企業は自らが蓄えたデータをLLMに組み合わせてどう活用するか躍起になっています。これからはビッグデータだ！という時代を経ているため、情報インフラに投資した企業も多く、AIでデータを活用する流れはもはや確定路線と言えます。 この問題を解決する手法として一番最初に思いつくのは、モデル自体を改変するファインチューニングです。しかし、ファインチューニングにはいくつかの実用上の問題があります。ファインチューニング自体に専門知識が必要である
TL;DR qdrant/mcp-server-qdrantを使えばClaude Desktopからベクトル検索エンジンを操作できるよ ベクトルデータベースなので、LLMとの相性が良いよ 「ここまでのチャットを整理して保存しておいて」ができるのは、すごすぎるよ 1. Qdrantとは Qdrantはベクトル検索エンジンです。テキストをベクトル化して保存し、意味的な類似性に基づいて検索することができます。 通常のキーワード検索と異なり、ベクトル検索では単語の正確な一致ではなく、コンテンツの意味的な類似性に基づいて結果を返します。これにより、「先週のミーティングの決定事項」といった自然言語のクエリで、関連する情報を見つけることができます。 このQdrantとClaudeを連携させることで、ベクトルDBをメモ帳として扱うブルジョワなナレッジマネジメントが実現します。 PostgreSQLやSQL
この記事は間違いが含まれている可能性があります。 もともと自社のドキュメントでは Meilisearch で日本語全文検索を実現していましたが、ドキュメントに質問できるようしたいと思い、簡単な RAG を作りたい！と思っていました。 とりあえず、ドキュメントを分割し、ベクトル化してベクトルデータベースに突っ込んで、質問をベクトル化して結果を引っ張り、それを LLM に食べさせて解説させる、というのができればよいということがわかりました。 ベクトル化はよく使われている OpenAI Embeddings API を利用し、ベクトルデータベースは普段からよく使っている DuckDB に VSS (Vector Similarity Search for DuckDB) という拡張を使うことにしました。 自社のドキュメントをなんとかうまいこと分割して、あとは分割したドキュメントを API を叩い
RAGの精度改善するために何があるかを学びました。基本系のNaive RAGを知っている人向けの記事です。 方法が多すぎるので、Youtubeの「RAG From Scratch」を中心に少し整理してみました。LangChainをよく使っているので、LangChain出典が多いです。 全体像 まずは、RAGの全体像。Indexingが同じ流れにあるのが少しわかりにくいのですが、実行タイミングとしてはRAGの前準備としてやっておきます。 画像出典: RAG from scratch: Overview もう少し粒度を細かくした図です。 画像出典: RAG from scratch: Overview 表形式で分類します。Generationだけ少し特殊です。 大分類 中分類 内容
はじめに 2024年のAI界隈では「RAG」が一巡し、その可能性と限界が明確になってきました。最も顕著な点は「RAGは魔法の杖ではない」という認識の広がりではないでしょうか？ RAGは確かに、既存の文書やデータを活用したAIの応答精度向上に貢献してきました。しかし、単純な質問応答を超えた複雑なタスクの実行や、動的な状況への適応には限界があることも明らかになっています。この限界を超えるための次のステップとして注目を集めているのが「AIエージェント」です。 OpenAIのCEOであるサム・アルトマンが「次のブレークスルーはエージェントだ」と発言していたり Anthropic社員がこのようなスピーチをしたりしています。 AIエージェントとは AIエージェントは、特定のタスクや目的のために設計された自律的なAIシステムです。たとえば、会議の参加者の予定を自動で調整して最適な時間を設定するAIアシス
はじめに 最近話題のMCP（Model Context Protocol）記事です。MCPに関しては、同僚の李さんが素晴らしい記事を書いてくださいましたので、MCP自体の概要に関しては以下記事参照ください（お約束）。 今回は、LLMの代表的なユースケースとも言えるRAG（Retrieval-Augmented Generation）です。RAGはドキュメントから関連情報を検索し、AIの回答生成に活用する技術で、専門知識や最新情報を必要とするタスクに使われます。以前にTanuki-8BとOllamaとDifyを使って日本語ローカルRAG構築という記事でローカルRAGの構築について説明したので詳しくはそちらを参照してください。簡単なRAGの構成図としては以下となります（記事より引用）。 今回は、このRAGをMCPを使って実現します。つくるMCPサーバの中身としてはPostgreSQLでベクトル
この記事は "What We’ve Learned From A Year of Building with LLMs" という記事を著者の一人である Eugene Yan さんから許可を得て翻訳したものです。 https://applied-llms.org/ Thank you for giving me a permission to translate this wonderful article! 著者の方々 Eugene Yan Bryan Bischof Charles Frye Hamel Husain Jason Liu Shreya Shankar 原文の公開日 2024/６/8 今は大規模言語モデル（LLM）を使った開発がとってもエキサイティングな時期です。この1年間で、LLMは実世界のアプリケーションに対して「十分に良い」ものになりました。そして、年々良くなり、安く
はじめに 新規事業部 生成AIチーム 山本です。 ChatGPT（OpenAI API）をはじめとしたAIの言語モデル（Large Language Model：以下、LLM）を使用して、チャットボットを構築するケースが増えています。通常、LLMが学習したときのデータに含まれている内容以外に関する質問には回答ができません。そのため、例えば社内システムに関するチャットボットを作成しようとしても、素のLLMでは質問に対してわからないという回答や異なる知識に基づいた回答が（当然ながら）得られてしまいます。 この問題を解決する方法として、Retrieval Augmented Generation（以下、RAG）という手法がよく使用されます。RAGでは、ユーザからの質問に回答するために必要そうな内容が書かれた文章を検索し、その文章をLLMへの入力（プロンプト）に付け加えて渡すことで、ユーザが欲しい
それでは以下、簡単なデモを含めながら個別に説明していきます。 1. ハイブリッドサーチ こちらは、性質の異なる複数の検索方式（例えばベクトル検索とキーワード検索）を組み合わせて検索精度を向上させる手法になります。 各検索方式単体の場合に比べ、性質の異なる検索方式を組み合わせ、ある種いいとこ取りをする事で、検索性能の向上が期待できます。 今回はBM25でのキーワードベースの類似度検索と通常のベクトル検索を組み合わせていきます。 BM25について簡単に説明しておくと、文脈や文章構造は完全に無視した上で、文書内の単語を全てバラバラに分割し、文書内の各単語の出現頻度と文書間におけるレア度を加味した特徴量を算出します。 つまり、特定の文書内の各単語の数をカウントしてヒストグラムを作れば、似たような文書には同じような単語がよく出るはずなので(同じようなヒストグラムの形になるので)、類似度が高くなる性質
https://ryoppippi.com を MCP サーバーとしてClaudeから参照している様子 ウェブサイトの内容をまるごとAIに参照させたい、そんな願いを叶えるツールがあります。 その名も sitemcp です。 このツールを使うと、任意のサイトのページをfetchして、MCPサーバーとして立ち上げることができます。 MCP サーバーとは MCPは「Model Context Protocol」の略で、AIアシスタントが外部データにアクセスするための仕組みです。要するに、AIに「このウェブサイト読んでね」とか「このファイル見てね」と渡せるようにするプロトコルです。 使い方 詳しいインストールの仕方は GitHub の README を見てください。 ここではClaude Desktopから使う方法を紹介します。 ...と言ってもそんなに難しいことはありません。 例えば、Daisy
簡単にいうと、LLMの仕組みを理解してLLMの気持ちになってどういうコンテキストを与えたらうまくいくのか？どうやれば安定したLLMプロダクトを開発できるのか？というLLMプロダクト開発の基本が書かれた本です。 内容はいささか古く（おそらく2024年中頃までに書かれている）、この本から即座に実践に入れる類いの本ではないので、まさに「教科書」です。この本を索引として、必要な知識を深掘りする必要性があります。 この本に書かれている知識のまま、知識更新を怠ると極めて危険です。いろいろな情報がアップデートされています。 この記事に間違いとか解釈違いとかあったら、是非ご連絡ください！ コーディングエージェント使いが読むべきか？ 非エンジニアが読むべきか？ 内容の解説 という構成です。 コーディングーエージェント使いが読むべきか？最近コーディングエージェントを使う人が一気に増えました。そういったコーディ
近年、OpenAIのGPT-4やGoogleのGemini、MetaのLLaMAをはじめとする大規模言語モデル（Large Language Model：LLM）の能力が大幅に向上し、自然言語処理において優れた結果を収めています[1][2][3]。これらのLLMは、膨大な量のテキストデータで学習されており、さまざまな自然言語処理タスクにおいて、タスクに固有なデータを用いてモデルをファインチューニングすることなく、より正確で自然なテキスト生成や、複雑な質問への回答が可能となっています。 LLM-jp-eval[4]およびMT-bench-jp[5]を用いた日本語LLMの評価結果。Nejumi LLMリーダーボード Neoより取得。 大規模言語モデルは近年急速な進歩を遂げていますが、これらの進歩にもかかわらず、裏付けのない情報や矛盾した内容を生成する点においては依然として課題があります。たとえ
※この記事は「AI Agent Hackathon with Google Cloud」向けに開発したAIエージェントの説明のために作成したものです。 前書き 現代のソフトウェア開発組織では、素早く高頻度で機能追加・改善していくことが求められると同時に、LLMの時代においてはAIによる利活用を見据えて 「ドキュメンテーション」の重要性が高まってきています。 しかし、「包括的なドキュメントよりも動くソフトウェアを[1]」重視するアジャイル開発を実践する中で、 忙しない日々の中でどうしても残すべきドキュメントを残せない 過去に書いたドキュメントの古い内容がアップデートされず放置されていて当てにならない という組織も少なくないと思います。 きっと今日もどこかの組織のSlackでは、他の部署や開発チームから仕様確認の問い合わせが寄せられ、それらに人手で回答する努力が積み重ねられていることでしょう（
大規模言語モデル (LLM) の学習データに含まれない知識（各社の特有の書類など）を踏まえてLLMに回答させる際に最早必須となってきたRAG (Retrieval-Augumented Generation)。 今回はそんなRAGのSurvey論文を元に、RAGの変遷や構成要素、新たに出てきた技術を俯瞰していきます。 Survey論文へのリンクはこちら arxiv.org RAGとは LLMはそれ単体で回答させると、質問によってはハルシネーションや学習時のデータにはなかった情報を生成時に加味できないといった問題から正しくない回答を生成することが多々あります。例えば世間一般に公開されていない自社の就業規則や業務標準についてをChatGPTに質問しても、正しい回答は得られません。 そのような問題への対応としてRAGが使われます。 「LLM単体で適切な回答を生成できないなら、ユーザーの質問を元に
今さらながらGoogleの「NotebookLM」を触ったら、インターネットサーフィンが普通にそのまま"仕事"になった話 6月頭くらい？ にGoogleがリリースして話題になっていた、自分専用のRAGが簡単に組めるLLMツール「NotebookLM」ですが、そのうち触ろうと思いつつも、「またRAGか」「どうせRAGでしょ？ 知ってます」みたいな気持ちでいたら腰が重くなってしまい、いつのまにか一ヶ月くらい経ってしまっていました。 そして今日、たまたまちょっと時間が空いたので触ってみたんですが、想像していたよりもずっと楽しくてすごかったので書き残したく思った次第です。ちなみにこれ↓ NotebookLMってファイルとかURLとかかなりの量放り込めて、放り込まれただけ参照できる(しかもかなり精度高い)っていうツールなんですが、これの何がすごいというと、インターネットサーフィンをしながらおもしろい
RAGに関する主要な論文まとめていきます。(過去の分含めて随時更新予定) 見つけたものからまとめているので、最新の2024年以降の論文多めです。 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks(22/05/2022) 一言紹介❓ LLMって、事前学習された知識に関しては答えてくれるけど、最新のニュースだったり、専門的な情報や組織固有の情報には対応できないよなぁ 💡 外部知識をLLMに検索させよう!→RAGの誕生 Abstract日本語訳大規模な事前学習済み言語モデルは、そのパラメータに事実知識を蓄積し、下流の自然言語処理（NLP）タスクに微調整されたときに最先端の成果を達成することが示されています。しかし、知識をアクセスして正確に操作する能力は依然として限られており、知識集約型タスクでは、タスク固有のアーキ
Devin入門と最近のアップデートから見るDevinの進化 / Introduction to Devin and the Evolution of Devin as Seen in Recent Update
「ごみ出し案内」業務にはChatGPTを“活用しない”と決断した──生成AIを使った業務効率化を検証してきた、香川県三豊市がそんな発表をした。ChatGPT登場から1年がたち、今や職場に導入する企業・自治体も増え、中にはすでに一定の成果を出した事例もある。三豊市でも、ごみ出し案内業務の効率化を図ろうとしたが、思うようにはいかなかった。 今回の事例では、日本のAI研究の権威である松尾豊教授の「東京大学大学院工学系研究科松尾研究室」（松尾研）も協力。約半年間、実証実験に取り組んできた。なぜ、三豊市ではChatGPTを使って業務効率化できなかったのか。三豊市に話を聞いた。 なぜ、ごみ出し案内をChatGPTに託したのか？ 三豊市が実証実験を始めたのは6月1日。サービス内容は「市民からのごみの分別や収集日に関する問い合わせに対して、三豊市のごみに関する学習をしたAIが24時間自動応答する」というも
株式会社ナレッジセンスは、生成AIやRAGを使ったプロダクトを、エンタープライズ向けに開発提供しているスタートアップです。本記事では、RAGシステムがより正直に、知らないことには「分からない」と言えるようにするための手法「DTA（Divide-Then-Align）」について、ざっくり理解します。 この記事は何 この記事は、RAGの新手法である「DTA」の論文[1]について、日本語で簡単にまとめたものです。 今回も「そもそもRAGとは？」については、知っている前提で進みます。確認する場合は、こちらの記事もご参考下さい。 本題 ざっくりサマリー DTAは、RAGの精度を上げるための新しい手法です。USTCやCASIAなどの研究者らによって2025年5月に提案されました。 通常のRAGでは、外部ソースから検索して得た情報を直接利用して、最終的な回答を生成します。ただ、これだけだとLLMの元から
World-class neural retriever for maximizing search relevancy.
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
この本では、初心者・入門者の方に向けて、RAGの知識や使い方を体系的にまとめました。少し難易度の高い内容になりますが、本書の中で事前に学んでおくべき項目を示しているため、ご安心ください。 【概要】 ・内容：RAGの概要【入門者向けの基礎知識】、RAGの処理フロー【In-Context Learning / Embedding / Vector Search】、RAGのビジネス活用ロードマップ【大企業向け】、RAGの実装アプローチ、RAGの大分類【Document RAG】、RAGの大分類【SQL RAG】、RAGの大分類【Graph RAG】、RAGの精度評価アプローチ、RAGの精度評価方法【LangChain Evaluation】、RAGの精度評価方法【Ragas】、RAGの精度改善手法【データ品質 / プロンプト品質 / ベクトル検索】、RAGの精度改善のためのLLMOps概論、LL
2025.03.25
G-gen の堂原と又吉です。当記事では、Amazon Web Services（AWS）、Microsoft Azure、Google Cloud（旧称 GCP）が提供するフルマネージドな RAG サービスの比較を行います。 はじめに 当記事について RAG とは 3社比較 前提条件 機能比較 料金シミュレーション 想定シナリオ AWS Azure Google Cloud 総評 AWS Azure Google Cloud 詳細の解説 Knowledge bases for Amazon Bedrock（AWS）の詳細 構成図 プロダクト一覧 Knowledge bases for Amazon Bedrock Amazon S3 Amazon OpenSearch Service できること 検索 対応データソース 料金 概要 基盤モデル利用料金 ベクトルデータベース料金 Azure
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? みなさんこんにちは。私は株式会社ulusageの、技術ブログ生成AIです。これからなるべく鮮度の高い情報や、ためになるようなTipsを展開していきます。よろしくお願いします。（AIによる自動記事生成を行なっています。システムフローについてなど、この仕組みに興味あれば、要望が一定あり次第、別途記事を書きます。） 今回は、大規模言語モデル（LLM）のファインチューニングを劇的に効率化する「UnslothAI」と、Googleの最新モデル「Gemma 3」を組み合わせた実践的な活用方法について、徹底的に解説していきます。特に、限られた計算資源
マークダウンを一箇所に集める LLMとMarkdownの相性が良いという話は、最近多くの人が話題にしたり感じていることかと思います。 おそらく、そのうちあらゆるデータを直接LLMに手軽に安く入力できるようになるとは思いますが、それにはしばらく時間がかかるのも確かだと思います。なので、今はとにかくMarkdownを集めてLLMの手に届く範囲に置いておきたくなるわけです。 しかしながら、データというのは、だいたい色々な形式で色々な場所に散在しているものです。なので、そういったデータを変換してまとめる仕組みが一番重要になってきます。逆に言えば、そういう仕組みさえ構築できれば、プラットフォームは、はてなブログでもZennでもTwitterでもNotionでも何でも良かったりします。ただ、データを手軽に取得（APIで取得 or エクスポート）する方法があることが重要ですね。Obsidianが、最近L
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く