GitHub MCPサーバーの実践的活用例
はじめに
開発の現場でAIを活用する方法は、日々進化を続けています。 その中でも個人的に注目しているのは、CursorとGitHub MCPサーバーの組み合わせです。 この組み合わせにより、GitHub Pull Requestの作成やレビューといった作業にも、Coding Agentの支援を受けられるようになります。 本記事では、実際に私が活用しているCursorとGitHub MCPサーバーの具体的なユースケースについて紹介したいと思います。
MCPサーバーの大きな魅力は、Cursorの機能を拡張できる点と、適切な権限管理が実現できる点にあります。これにより、AIを安全かつ効果的に開発プロセスに組み込むことが可能になります。
CLIではなくMCPサーバーである理由
私自身、最初は「AI AgentにCLIを渡せばMCPサーバーは不要になる」と考えていました。
GitHubの操作に関しても、ghコマンドを使えば十分だろうと。
しかし、実際に試してみると、CLIには以下のような限界があることが分かりました。
セキュリティと権限管理
データ取得の制限
出力の扱いやすさ
これらの理由から、AIと開発環境の橋渡しとして、MCPサーバーはCLIよりも適していると判断しました。
業務で役立つGitHub MCPサーバーの活用例
実際に私が業務で活用しているGitHub MCPサーバーの活用例を4つ挙げたいと思います。 私はCursorを利用していますが、VSCode, Claude Codeでも同様の挙動は実現できると思います。 以降Pull RequestのことをPRと呼びます。
Pull Requestの概要をAIに書かせる
ファイルの変更だけのDraft PRを作成し、そのDraft PRのURLをAIに渡すことで、AIはそのPRの変更差分を取得することができます。 そしてAIにそのファイルの変更差分から、PRの概要を書いてというプロンプトの指示をすると、PRの概要を網羅的に適切な粒度で手早く書くことができます。 PRテンプレートがあると、より安定して概要を書かせることができます。 PRの概要を書くのは、一定のコストがかかりますが、コードの意思決定を遡る際に重要な手がかりになります。 PRの概要のドラフトをAIに任せることで、AIが読み取れない人間が下した意思決定を言語化するのに、人間の思考リソースを使うことができます。
Pull RequestのレビューをAIにさせる
PRのURLをAIに渡すことで、AIはそのPRの変更差分とコメント履歴を取得できます。 AIに「このPRをレビューして」と指示すると、コードの変更点を分析し、潜在的な問題点や改善提案を提示してくれます。
特に効果的なのは、AIとの対話的なレビュープロセスです。AIの指摘に対して「なぜその指摘をしたのか」と問いかけたり、「この部分は意図的にこのように実装した」と説明したりすることで、レビューの精度を高めることができます。 GitHub Copilot Reviewer や Claude Code Action のように、AIがPRの変更点をレビューする機能は増えつつあります。 ただ、AIと対話しながらレビューすること、また必要に応じてPR以外のソースコードを参照できることは、エディタ上のMCPサーバーを利用している利点です。
Pull Requestのレビューの打ち返しを支援させる
レビューコメントが付いたPRのURLをAIに渡し、「このレビューコメントにどう対応すべきか」と問いかけることで、AIは各コメントの意図を解釈し、具体的な対応案を提案してくれます。
長文のレビューコメントでも、AIは一つずつ丁寧に分析し、それぞれの指摘に対する適切な対応方法を提示します。 これにより、レビュー対応の負担を軽減しつつ、重要な指摘を見落とすリスクを減らすことができます。 必要に応じてAIのレビューの問題点を指摘し、より良いレビューを実現できます。
Pull Requestの速読・コード考古学を補助させる
コード考古学とは、そのコードがなぜそのような実装になっているのか、過去のログを調べて探すことです。 GitHub MCPは、この作業を効率化するツールとなります。
具体的な活用方法は以下の通りです：
コードの変更履歴の追跡
- 特定のコードの変更が含まれるPRのURLをAIに渡す
- AIが関連するPRの情報を取得し、変更の背景や意図を要約
- 「このコードはなぜこのように実装されているのか」という問いに対して、実装の経緯や意思決定の背景を説明
詳細な調査のための手順
git blameで特定の行のコミットハッシュを取得gh pr list --search "<commit hash>" --state allでコミットハッシュが含まれるPRを検索- 見つかったPRの内容をAIに分析させ、実装の意図や背景を理解
このように、PRの速読とコード考古学を組み合わせることで、コードの文脈を素早く理解し、適切な判断を下すことができます。
その他の活用の可能性
現在はGitHubとの連携に焦点を当てていますが、Cursorの可能性はさらに広がっています。 以下は、今後Cursor上で試してみたいと考えている開発プロセスにおけるAI活用方法です。
Notion / Linear MCPとの連携
- タスク管理や設計ドキュメントの文脈をAIが理解できる
- プロジェクトの全体像を把握した上での支援が可能になりえる
Design DocやADRの分析
- PRの背後にある意思決定や設計背景の理解
- 設計意図に基づいたコードレビュー
- アーキテクチャの一貫性チェック
- テキストファイルでの受け渡しは現状でも可能ですが、動的に必要なファイルを特定し、提供する仕組みが欲しいです
まとめ
AIにコードのすべてを任せるにはまだ不安があります。しかし、Pull Requestやレビューといった「AIに任せるにはちょうど良い粒度の業務」から導入していくなら、MCPサーバーを用いたこのアプローチは非常に有効だと思います。 もし他の活用事例があればぜひ共有してもらえると参考になります。
SINIC理論に関する本を読んで考えたこと
SINIC理論 過去半世紀を言い当て、来たる半世紀を予測するオムロンの未来学を読みましたので、その感想を記します。
モチベーション
Xのフォロワーが度々SINIC理論というものに言及しており興味を持ちました。 その時点での自分の理解は、SINIC理論というものは、現代の最適化社会を数十年前に予測していた理論ということでした。 SINIC理論を体系的に解説している本を読みたいと思い、本書を手に取りました。
AIの発展により社会が急速に変容していっています。 SINIC理論はこの世界が行き着く先の1つを示しているのではないかと考えています。 未来を知ることができれば生き方、キャリア、働き方、作るプロダクトの方向性に関わると考えています。
本の概要と目次
この本は、オムロンの創業者である立石一真氏が提唱したSINIC理論を解説し、過去の予測と結果を振り返り、SINIC理論のアップデートを行い、未来社会の展望を示す内容となっています。 目次は以下の通りです
- 未来を考えるということ - 未来予測理論「SINIC理論」 - よりよい未来づくりへのSINIC理論アップデート - 現在進行形の「最適化社会」のゆくえ - 自律社会を生きる人、自律社会を支えるテクノロジー - SINIC理論を超えていく未来 - 共に未来をソウゾウする
SINIC理論とは
SINIC理論とは、Seed-Innovation and Need-Impetus Cyclic Evolution of technological innovationの頭文字を取ったものです。 「サイニック」と呼ぶようです。 SINICを和訳すると、「科学が技術の種となり、技術は社会を革新する。そして、社会は技術に新たなニーズを与え、技術はその社会的価値によって、さらなる科学の発展に刺激を与える。そのような、円環的な技術革新の進化」になります。 科学・技術・社会の三者の相互の影響による、技術革新の円環的進化を、未来予測理論として体系化したものです。 以下の図として表現されています。
OMRON 未来への羅針盤「SINIC（サイニック）理論」より引用
SINIC理論のアップデート
SINIC理論が提唱されたのは1970年で、半世紀以上前に現在の「最適化社会」の到来を予測していました。 SINIC理論は単なる予測の当たり外れだけではなく、その理論体系を深く理解し、そこから導かれるシナリオの必然性を理解することが重要だとされています。 SINIC理論を今後も活用し、未来社会を「より良いもの」として多くの人々と共有し、共感を得るためには、理論のアップデートが不可欠だとあると判断されました。 具体的には、この半世紀の間の「地球環境の変化」、「科学技術の革新」、そして「人間の志向性や社会の価値観の変化」という三つの影響が、理論のアップデートを必要とする背景となりました。
SINIC理論は以下の3つの補助理論があり、それらがどのようにアップデートされていったのか見ていきます。 1. 科学技術社会論 2. 社会発展指標とプロセスの理論 3. 社会進化と価値観の理論
1. 科学技術社会論
この理論は、SINIC理論の「背骨をなす」特徴であり、科学と技術と社会の円環的な相互作用を説明します。
- 元の理論的特徴:
- 科学は技術の「種」となり、技術は社会を「革新」します。
- 革新を遂げた社会は、技術に新たな「必要性」を与え、技術はその社会的価値によって、科学にさらなる発展への「刺激」を与えます。
- この円環的相互作用の原動力は、「人間の進歩志向意欲」と位置づけられ、これが科学に「探究」、技術に「研究・開発」、社会に「教育訓練・適応」という行動を促すとされていました。当時の図解では、科学と社会の間は点線で示され、直接的な相互作用は明記されていませんでした。
- アップデートが必要な理由:
- 高度経済成長期を経て社会が成熟期に入り、経済の量的成長が鈍化したことで、従来の「進歩志向意欲」では社会発展が収束してしまう懸念が生じました。
- 地球環境問題や多様性の尊重といった新たな課題が顕在化し、人間は成長だけでなく他者や環境との「共生」を志向するようになったため、従来の原動力のままでは持続可能な発展が見込めなくなりました。
- 科学と社会の関係性も大きく変化し、社会が科学に対して単なる恩恵の源泉として信頼するだけでなく、批判的な視点や倫理的な問いを投げかけるようになったため、双方向の相互作用を明確にする必要がありました。
- アップデートされた理論的特徴:
- 科学と社会の間に、「可能性（期待）」と「夢」という相互作用が加わり、さらに社会から科学に向けて「倫理（個人的で具体的な問い）」が投じられるようになりました。
- 円環的相互作用の原動力は、「人間の進歩志向意欲」から「共生志向意欲」へと転換されました。
- 人間の社会への行動は、変化に「適応」するだけでなく、「新しい未来社会を創り、たぐり寄せるための『参画』」という主体的な行動が必要であると修正されました。
2. 社会発展指標とプロセスの理論
この理論は、社会発展のレベルと、その進展プロセスをどのように捉えるかに関するものです。
- 元の理論的特徴:
- 社会発展度を測る最適な指標として、「国民一人当たりGNP（国民総生産）」が選定されました。これは高度経済成長期において、個人の購買力と社会の豊かさが同等と見なされていた時代背景を反映しています。
- 社会発展のプロセスは、ロジスティック曲線（成熟曲線）に近似させて考えられ、一人当たりGNPが4万米ドルを超えた時点で「自律社会」という成熟段階を迎えると推定されました。
- アップデートが必要な理由:
- 2022年時点で日本の一人当たりGNI（GNPの現在の指標）が4万1513米ドルとなり、すでに低成長時代が到来しているなど、従来の経済指標による社会発展の予測が現実化しています。
- しかし、成熟期を迎えた現在では、経済の量的成長が鈍化しており、従来の経済指標だけでは社会の豊かさや幸福度を測ることが困難になっています。
- 「GDP等の経済指標では、社会の豊かさや、幸福度は測定できない」という認識が世界中で広まっており、気候変動や貧困格差などの複合的な課題を考慮した、多様な価値基準に基づく指標が必要となっています。
- アップデートされた理論的特徴:
- 「単一の経済指標を尺度として測る社会発展」から、「社会を構成する一人ひとりの価値観」の基準に基づいた、「一人ひとりの幸せの向上の社会総和」という多元的な指標で社会発展を捉える考え方が導入されました。
- これにより、「人々の生活の質（well-being）」と「地球環境の持続可能性（Sustainability）」の観点が今後の豊かさを測る上で重要視されています。
3. 社会進化と価値観の理論
この理論は、社会進化の方向性が、その社会の中心的な価値観によって決まるとするものです。
- 元の理論的特徴:
- 人類史は原始社会の「心」の世界から始まり、工業社会で「物」の世界へと進み、その後再び「心中心の価値観」へと回帰するという二元的な価値観の循環がプロセスに取り入れられました。
- この「心」か「物」かという二元論に、「集団中心社会」か「個人中心社会」かという観点も加えられ、「心と集団」が中心の社会と、「物と個人」が中心の社会を行き来する進化構造が設定されていました。
- 社会進化は、円錐形の側面を頂点に向かって螺旋状に登り上がっていくとされ、時間の経過とともに進化の速度が加速することも示唆されていました。
- アップデートが必要な理由:
- アップデートされた理論的特徴:
- 「心」か「物」かという対抗軸と、「集団」か「個人」かという対抗軸の独立した2軸による座標平面を、社会発展の針路を表す構造として設定するようになりました。
- これにより、価値観領域だけでなく、価値観の強弱やバランスも表現できるようになり、社会が円錐上を登って発展していく中で、最適なバランスの価値観に収束していくことが示せるようになりました。
- 現在は、「最適化社会」から「自律社会」への移行期にあり、「心中心」に向かい、かつ「行き過ぎた個」の価値観を是正し「集団」（つながり）の価値観側に進み始めているステージにあるとされています。
考察
本書を読み、特に興味深く感じた点について、私自身の考えを記します。
「暇」の価値の高まり
従来の大量生産・大量消費を前提とした経済活動は、現代社会に物質的な豊かさをもたらした一方で、環境破壊や資源枯渇といった負の遺産も残しました。 本書ではこれからの社会では「機械にできることは機械に任せ、人間はより創造的な分野での活動を楽しむ」という方向へシフトしていくのではないかと述べられていました。
それは、古代ギリシャ時代のような世界観の復活を想起させました。 古代ギリシャでは、市民は家事などの労働を奴隷に任せ、芸術や学問といった創造的な活動に没頭していました。 これからの時代、その奴隷の役割を機械やAIが担うことで、人は多くの「暇」を手にすることになり、その生まれた時間を使って、芸術や学問に再び時間を費やす時代が来るのかもしれないです。 そのとき、創造的な活動そのものの価値が、相対的に高まると思います。
「心中心の価値観」の再来と現代カルチャー
本書で示された「心中心の価値観」への回帰は、現代のカルチャーの中にその兆候を見出すことができます。 特に「推し活」と「写真映え」は、その価値観を象徴する現象だと考えられます。
- 推し活: 物質的な所有よりも、特定の対象（アイドル、アニメキャラクターなど）への精神的な繋がりや共感、愛着といった感情的な価値を重視する活動である。対象を応援すること自体が喜びとなり、コミュニティの一員としての帰属意識や、他者との共感・共有体験に価値を見出す点で、「心」と「集団（つながり）」を中心とする価値観に合致します。これは、個人の意志や行動が共感によって評価される「評価経済」への移行を示唆しています。
- 写真映え: 単に物を所有するだけでなく、その物や体験を通じて「感性」や「経験」の価値を追求する傾向の現れです。物理的な「物」（写真の被写体）は介在するものの、そこから得られるのは、美的感覚の充足や共有体験、他者からの承認といった精神的な満足感です。これは、価値観が「モノからコトへ」と転換し、消費の動機が「所有欲」から「承認欲求」へとシフトしていることを反映しています。
最適化社会の実態と、それに対する私のスタンス
かつて、人々が触れる情報は新聞やテレビなどに限られており、画一的で共通の体験が生まれやすかったです。 例えば、小学校の頃には「昨日のテレビ番組の〇〇が面白かった」という共通の話題で誰もが盛り上がれたものです。 しかし、YouTubeやSNSの発達によってコンテンツは氾濫し、個人が摂取する情報は細分化されました。その結果、共通の話題を持つこと自体が難しくなっています。 Amazonでレビューを参考に本を選び、Google Mapsで最短経路を検索し、食べログで評価の高い店に入り、Netflixにおすすめされた動画を観る。こうした日常の行動は、すべて最適化社会を象徴しています。
私自身、多くの場面でアルゴリズムや他者のレビューに判断を委ねすぎていると痛感しています。だからこそ、意識的に自らの選択に自信を持ち、偶然の出会いを楽しむようにしています。 いつもと違う道を通ってみる、地図で気になった場所に旅をする、直感で店に入る、居酒屋で知らない人に話しかけてみる、といった具合です。 根底には、他人と同じことはしたくないという反骨精神があるのかもしれません。
「自律社会」はどこから始まるのか
最近では、ChatGPTに自らの意思決定を委ねる場面も増えてきました。就職先の比較検討、購入予定の製品のリサーチ、日々の思考整理など、その用途は多岐にわたります。 これらの行為は、個別最適化をさらに強化するものなのか、それともSINIC理論の示す「最適化社会」の次のフェーズへの移行を示唆しているのだろうかと考えています。
さらに、DevinやClaude Codeといったコーディングエージェントが注目を集めています。これらは、技術が自律的に動作し、自己改良さえ行う時代の到来を予感させます。このような技術の動向は、まさしく「自律社会」の一端ではないでしょうか。自律社会の到来を告げる号砲は、こうしたコーディングエージェントから鳴らされるのかもしれません。
まとめ
SINIC理論が半世紀以上前に提唱され、それが現在までの社会と科学技術を予測しており、その先見性には驚嘆しています。 またオリジナルのSINIC理論が想定できていなかった社会情勢を考慮してアップデートされたSINIC理論も、妥当性のあるもののように見えました。 これからの自律社会を形作る一員として、技術に使われるのではなく、技術を適切に利用・運用する側になるように日々過ごしていきたいと思います。
人生で初めて楽器を買った話
先日エレキギターを買ったので、その経緯と所感について書きたいと思います
音楽コンプレックスの原点
私は昔から音楽に対して苦手意識がありました。小学校の頃に使っていた鍵盤ハーモニカやリコーダー、合唱などはあまり好きではありませんでした。 また、リズム感覚がなく、拍についてもよく分かっていませんでした。 音楽の授業は退屈に感じており、テストのときには一応勉強しましたが、面白いとは思えませんでした。 高校生のとき、初めて「拍」というものを意識して理解したのを覚えています。
演奏への興味の芽生え
あるとき、自分の音楽コンプレックスについてふと考える機会がありました。 「聞く側」から「演奏する側」になれば、音楽への解像度が上がるのではないかと考えたのです。 実際に楽器を演奏している友人たちの話を聞いてみると、その考えはあながち間違っていないと感じました。
新しい趣味を求めて
私は普段、仕事や趣味のソフトウェア開発、Netflixの視聴など、四六時中ディスプレイを見る生活を送っています。 画面を見ない趣味としては水泳やランニングがありますが、どちらも1日あたり2時間ほどが限度で、それ以上続けるのは体力的に難しいと感じています。 さらに、施設に行く必要があったり、天候に左右されたりと、多少の手間もあります。 そのため、自宅でできて、なおかつディスプレイを見ずに取り組める趣味が欲しいと思うようになりました。
ギターとの出会い
ギターに詳しい知人に案内してもらい、楽器の街・御茶ノ水に行きました。 御茶ノ水は通りのほとんどが楽器店で埋め尽くされており、「楽器の街」という呼び名にふさわしい場所だと感じました。 事前知識はゼロでしたが、さまざまなギターに実際に触れることができて、とても貴重な体験になりました（予習せずに行ってしまってすみません）。 知人からは「賃貸の防音ではない環境であれば、エレキギターが良い」というアドバイスをもらいました。
ショップ巡りと選定基準の発見
知人の案内で、最初は3桁万円の高級ギターを扱うお店からスタートし、徐々に価格帯の低い店舗へと回りました。 最終的には1桁万円のギターを扱う店まで巡り、10店舗近くを訪れたことになります。 その過程で、自分の中で「ギターに対する選定基準」のようなものがだんだんと浮かび上がってきました。 形状、色、価格、そして手触りが、自分にとっての決め手になるのだと気づきました。 何店舗か巡るうちに、強く印象に残ったギターが出てきたため、そのギターを改めて見に行くことにしました。
YAMAHA PACIFICA611VFMに決めた理由
最初に手に取ったギターは、YAMAHAのPacifica 100シリーズの赤いモデルでした。 ギターを弾けないなりに試奏させてもらい、手触りを確かめてみました。 すると、ネックのあたりの仕上げが若干粗く、使い込むとすぐに毛羽立ちそうな感触がありました。 そのとき、店員さんから「こちらも試してみては？」と紹介されたのが、Pacifica 600シリーズのモデルでした。 100シリーズと比べてネックの手触りが明らかに良く、おそらく塗装の仕上がりが丁寧なのだと思います。 その日、複数の楽器店を巡った結果として「ギターは奏者にならないと、音の質や求める機能が分からない」という結論に至りました。 演奏する当事者になることで見えてくる世界もあると信じて、とりあえずやってみよう・まず買ってみようの精神で、YAMAHA Pacifica 611 VFMを購入することにしました。
ギターを買ってから
現在は単弦でドレミの音を出すところから練習しています。 弦を押さえる指がかなり痛いです。 リズム感に変な癖がついてしまうと、あとで矯正が難しいと聞いたので、まずはリズム感覚を身につける練習を優先しようと思っています。 気長に、ゆっくりと続けていくつもりです。 好きなアーティストであるBUMP OF CHICKENの曲を何か一曲弾けたらいいなくらいの気持ちで取り組んでいます。
余談
購入したギターは、アニメ「ぼっち・ざ・ロック！」に登場する、ぼっちちゃんの2代目のギターと同じモデルらしいです。 今このギターを買うと、ミーハーだと思われることもあるそうです。 私自身もアニメは視聴していましたが、ギター購入に際して「ぼっち・ざ・ロック！」から直接的な影響を受けたわけではありません。 「ミーハーに見られるかもしれないな」と思いつつも、演奏を他人に見せるつもりもないので、「そういう認識の人もいるのだな」程度に受け止めています。 ただし、無意識のうちにアニメの影響でギターの形状に好みが出ていた可能性はあるな、とも思っています。
「SOFT SKILLS」を読んで、自分の暮らしと向き合った
この記事の概要
ソフトウェア開発者向けの人生設計書『SOFT SKILLS 第2版』を読んで感じたことをまとめました。
書籍の要点だけでなく、自分のキャリア・学習・運動習慣にどう影響を与えたかを率直に振り返っています。
等身大の視点から、自分の暮らしを見直すきっかけとして読んだ記録です。
書籍の概要
本書はソフトウェア開発者がより良い人生を送るためのノウハウやスキルを幅広く網羅した一冊です。 キャリア構築やセルフマーケティング、学習法、生産性向上、資産形成、フィットネス、マインドセットといった多角的な視点から、仕事や人生で成功するための具体的な方法が解説されています。 各章は独立して読みやすく構成されており、自分の興味に合わせて必要な部分を選んで学べるようになっています。
本書の目次は以下の通りです。
- キャリア - キャリアをビジネスとして扱う - キャリア目標の立て方 - 社交スキルの向上 - 履歴書の作成方法 - 面接対策 - キャリアパスの種類 - 専門特化の重要性 - 企業の種類 - 出世方法 - プロとしての姿勢 - 職場での人間関係 - テクノロジーへの姿勢 - 独立と自由の獲得方法 - フリーランスの始め方 - プロダクト起業の方法 - スタートアップの起業 - リモートワークの活用 - セルフマーケティング - 基礎知識 - パーソナルブランドの確立 - ブログ戦略 - YouTubeによる発信 - 他者への価値提供の重要性 - ソーシャルメディア活用 - プレゼンや講演活動 - 書籍や記事の執筆 - 学習 - 学び方の学習 - 学習の10ステップ - 一度限りのステップ - 繰り返し行うステップ - メンターの見つけ方 - メンターとしての活動 - 教えることの効用 - 学位の必要性 - 知識の空白を探す - 生産性 - 集中の重要性 - 個人的な生産性メソッド - ポモドーロテクニック - クォータシステム - 自己責任 - 並行作業の弊害 - 燃え尽き症候群への対処 - 時間浪費の原因 - ルーチンの価値 - 習慣の育て方 - 分解による効率化 - ハードワークの価値 - 行動の重要性 - 資産形成 - 給料の活用法 - 給与交渉 - 不動産投資 - 引退プランの理解 - 借金のリスク - 真の富の築き方 - 若くして引退する方法 - フィットネス - 健康の利点 - 目標設定 - 体重の増減 - モチベーションの管理 - 筋肉のつけ方 - 腹筋の作り方 - ランニングの導入 - 筋肉を保ちながら脂肪を落とす方法 - スタンディングデスク等の工夫 - テクノロジーの活用 - マインドセット - 心と身体の関係 - ポジティブ思考 - セルフイメージの変革 - 恋愛と人間関係 - おすすめの本 - 失敗への向き合い方 - コンフォートゾーンから出る - ストア哲学の実践 - 締めくくりの言葉
読後の感想と日々の生活の振り返り
本書を読んだ感想と、日々の生活でどのようなことを考え、実際に実践していること、できていないことを振り返ってみます。
キャリア
自分のキャリアを一つのプロダクトとして捉える考え方はとても興味深く感じました。 私は往々にして他者の考え方には厳しく評価できても、自分に対しては甘くなりがちです。 これはキャリアも例外ではないです。 そのため自身のキャリアを客観的に見つめ直すためには、プロダクトとして捉える視点は有効だと思いました。
目標を持つことの重要性も強調されており、目標があることで具体的にいつ何をすべきか計画を立てやすくなります。 目標設定なしに無策に経験を積んでも方向性が見えにくいという指摘には納得しました。 私自身は目標を持つことで選択肢が狭まるのではと恐れていたのですが、むしろ複数の理想像を持つことで迷いを減らし、より意味のある経験を積めるのだと感じました。
セルフマーケティング
セルフマーケティングの章では、特にブログを定期的に書くことの大切さが印象に残りました。 私も実際にブログの投稿数が増えるにつれて閲覧数が徐々に伸びているのを実感しており、改めて継続の重要性を感じました。 YouTubeへの動画投稿を推奨してますが、時間対効果が悪い & 自分自身YouTubeをあまり見ないため、ブログに集中することにしています（Netfilxはよく見ますが）。
学習
私は新しい技術を学ぶ際に、私はまず座学よりも実際に手を動かして試すことを重視しています。 概要を掴んだ後に仮説を立てて検証するプロセスが自分に合っていると感じており、著者の「手を動かして学ぶことの重要性」という主張に強く賛同しています。
私の以下のブログ記事は、この考え方を実践したものです。
yutashx.hatenablog.com yutashx.hatenablog.com yutashx.hatenablog.com
学習して自己完結するとそれで終わりですが、ブログとしてインターネットに公開することで、リアクションがついたり、記事をきっかけに新たな交流の場が生まれたりします。 そのような意味でも、ブログを書くことは学習の一環として非常に有意義だと感じています。
生産性
生産性向上についてはまだ自分にぴったりの方法を見つけられていません。 筆者の提案を参考にしながら試行錯誤し、自分に合った方法を模索していきたいと考えています。 焦らずに自分のペースで改善していくことが大切だと感じています。
資産形成
「最大の投資は自分自身」という著者の考えにはとても共感しています。 私も学生時代に書いた記事の「お金に対する考え方」という節で同じようなことを述べたことがあります。
社会人になってからも大枠の考え方は変わっていません。 自分自身への投資から、株式や不動産への投資へ切り替わるべきタイミングはいつ頃なのか思考を巡らせてはいた。 今の所の暫定的な結論としては、家族や家を持ったときなど守るべきものが増え、責任の範囲が自分一人ではなくなったときに、資産形成を本格的に考えるべきだと感じています。 そうでないうちは、まずは自分自身への投資を優先するべきだと思います。 ここ半年でそれを強く実感するようになり、最近では興味のあるサブスクやAIサービスには積極的にお金を使うようになりました。 また考え方として、迷う時間や比較にかける時間を減らし、素早く試して合わなければやめるという行動が経験値にもなり、効率的だと思います。 お金のハードルは参入障壁にもなりますが、それを越えることで得られる経験や話のネタは大きな財産になると感じています。
フィットネス
健康維持のための運動の重要性には私も賛同しています。 ただ、筆者が推奨する具体的な栄養摂取や運動方法については、自分の経験則と合わずあまり参考にしていません。 私は元々運動が好きで水泳やランニングを楽しんでおり、少食な体質もあって適度な体型を維持できています。 運動によって自信が持てるという点は大いに共感しています。 社会人になって同期のソフトウェアエンジニアが優秀だなと思うことが多々あり、それに比べて自分は劣っているなと感じることがあった（そもそも比較するべきではないという意見はごもっともなのだが、それを頭では分かっていても、半ば無意識で考えてしまうことがあった） そういうときがあっても「俺彼らに泳げば勝てるしな」みたいなことを考えて、精神を保っていたこともあった（その後、人それぞれに得意不得意があり、一概に比較できるものではないと頭が納得し、考えることはなくなたた。考える暇があったら自分が得意で人がやりたがらない仕事を積極的にやればいいことに気づいた。）
また、生活の充実には運動が欠かせないという筆者の考えにも共感しています。 私は出社後の退勤後に泳ぐ習慣を取り入れ、判断を減らしてルーティン化したことで無理なく継続できるようになりました。 仕事や学習、交友関係を充実させるためには一定の体力が必要だと信じており、運動の習慣化はその基盤になると感じています。
マインドセット
プラス思考はとても良い考えで、私も賛同しています。 自分の能力が足りていなくても気持ちがあれば前に進めると感じています。 また、ゲームや競技では敗北があるものの、人生やキャリアにおいては失敗はあっても敗北はないという考え方は励みになります。 失敗を避けたがる人が多い中で、それを乗り越えて糧にできる人は魅力的な話のネタを持つことになると思います。 ストア派哲学についても触れられていましたが、私自身もその考え方に近いものを感じており、今後さらに学んでみたいと思っています。
他のソフトウェアエンジニアのキャリアの考え方
この書籍の内容は考え方の一つとして捉え、自分に合った方法を見つけていくことが大切だと思います。 他のソフトウェアエンジニアのキャリアの考え方としては、以下の記事も参考になると思います。
syu-m-5151.hatenablog.com syu-m-5151.hatenablog.com
これらはnwiizoさんという日本のソフトウェアエンジニアの世代が近い方が書いている記事です。 そのためこの本記事を読む読者の方々は、書籍の著者よりも、紹介したブログの方がキャリアのおかれている状況が近いと思います。 長めの文章ではありますが、内容は非常に濃く、キャリアの考え方や実践方法について深く掘り下げられているので、ぜひ一読をおすすめします。 （先日母校である会津大学でも公演をされたらしく、自分が在学中にこの話を聞いていたらキャリア観が大きく変わっていたのではないかと思います。）
まとめ
本書はキャリアやセルフマーケティング、学習、生産性、資産形成、フィットネス、マインドセットなど、ソフトウェアエンジニアとしての人生をより良くするための多角的なアプローチを紹介しています。 読んで新たに実践しようと思ったことが多く、既に取り入れていた考え方も多かったため、自分の方向性に自信を持つことができました。 一方で栄養や運動法については自分の経験に基づいて判断しており、本書の内容を通じて改めて自分の考えを確認する良い機会となりました。 これからも自身のキャリアやライフスタイルを定期的に見つめ直し、引退するときに後悔しないことを目指していきたいと思います。
Slack MCP Agentの実戦改善録
概要
Slack MCP Agent を Azure Container Apps にデプロイした結果、ログ解析や MCP Server の増減に手間がかかるなど運用上の課題が判明しました。 logging／AsyncExitStack／Secret Volume を導入してデバッグ性と動的拡張性を強化し、コスト最適化と権限管理の筋道を整理しました。 残る課題は SQLite 永続化・コスト削減の仕組み化・乱数による振る舞い制御であり、Blob 連携やジョブ駆動のポーリングを軸に今後改善を進めたいです。
はじめに
以前公開した Slackで動くMCP Agentを作った を実際に運用してみて、見えてきた課題と改善策をまとめました。 yutashx.hatenablog.com 読者の皆さんが同様のエージェントを本番環境で走らせる際のヒントになれば幸いです。
運用で可視化された課題
クラウド上での運用
MCP Server を MCP Host のサブプロセスとして起動し、標準入出力で通信する都合から Azure Container Apps を選択しました。
デバッグ性とログ監視
ローカルでは即座に原因が分かったエラーが、クラウド上では追跡に時間を要しました。 レスポンスが返らない原因がコンテナ・エージェント・MCP Server のどこにあるのか判定しづらく、セッション単位で再現しにくい不具合も散見されました。
MCP Server 追加の手間
新しい MCP Server を追加するたびに config.json と app.py の両方を更新する二重管理が発生していました。
API Key などの秘匿情報は config.json に集約したい一方で、config.jsonとapp.pyの対応が崩れるとサーバーが起動せずエージェントも停止するという問題がありました。
データ永続化の欠如
Slack ユーザーと外部ツールのユーザーを突合させるための永続ストレージが存在せず、再起動のたびに紐付けが失われるという課題がありました。
改善アプローチ
標準化されたロギングと自己診断
Python 標準の logging モジュールでログを一元出力し、エージェント自身がそのログを読み取れる Function Tool を実装しました。 別セッションから障害セッションのログを即時に調査できるため、エージェントを使った原因究明ができるようになりました。
@function_tool async def agent_log_reader() -> str: """Read the log file.""" print("call agent_log_reader") with open("./log/app.log", "r") as f: return f.read() self.agent_log_reader = agent_log_reader
AsyncExitStack による動的 MCP Server 追加
config.json にサーバー設定を追記してコンテナを再起動するだけで、新しい MCP Server が動的に読み込まれる仕組みを AsyncExitStack で実現しました。 秘匿情報は Azure Secret Volume で管理し、コード側の修正は不要です。
async with contextlib.AsyncExitStack() as stack: # mcpServersのkey分だけMCPServerStdioを動的に生成し、ExitStackに登録 servers = [] for _, params in mcp_servers.items(): server = await stack.enter_async_context( MCPServerStdio(params=params, cache_tools_list=True, client_session_timeout_seconds=60) ) servers.append(server)
Azure OpenAI 採用理由
- 機密データ を保持でき、リージョンを日本国内に限定。
- Terraform で IaC 化し、将来的に全てのリソースを管理したい。
アーキテクチャとシーケンス図
上記の改善を踏まえたアーキテクチャは以下のようになります。
flowchart TD
subgraph Slack["Slack"]
S["Slack Workspace"]
end
subgraph System["System Layer"]
SYS["Event Router & State Manager"]
CFG["Secret Volume (config.json)"]
end
subgraph AgentLayer["Agent Layer"]
AG["Inference Agent & Agent Loop"]
T1("Function Tools")
SM("MCP Servers")
end
subgraph State
LOG[("app.log")]
DB[("SQLite")]
end
subgraph Azure["Azure Container App"]
direction TB
System
AgentLayer
State
end
S -- app_mention --> SYS
SYS --> AG
SYS -- write --> LOG
SYS -- SQL(read/write) --> DB
CFG --> SYS
AG -- call --> T1
AG -- stdio spawn --> SM
T1 -- SQL(read/write) --> DB
T1 -- read --> LOG
またユーザーが Slack でエージェントにメンションすると、以下のような流れで処理が進みます。
sequenceDiagram
participant U as ユーザー
participant S as Slack
participant A as Agent (app.py)
participant MCP as MCP Servers
participant FT as Function Tools
participant DB as SQLite
U->>S: メンション @agent 「〜して」
S->>A: app_mention イベント
A->>A: AsyncExitStack で<br>config.json を読み込み<br>各 MCP Server 起動
A->>MCP: 必要な MCP Server に stdio リクエスト
MCP-->>A: ツールリスト / 実行結果
alt DB が必要な場合
A->>FT: db_query()
FT->>DB: SQL 実行
DB-->>FT: rows
FT-->>A: 結果
end
A-->>S: 途中経過「検索中…」
A->>A: Runner.run() で推論完了
A-->>S: 最終回答をスレッド返信
未解決課題と次の一手
SQLiteの永続化
現在は高速で手軽な SQLite を採用しているものの、コンテナごと削除するとデータが失われるという致命的な問題を抱えています。 この弱点を補うために、定期バッチで azcopy を実行し、ローカルの app.db を Azure Blob Storage へアップロードする方式を検討しています。 Blob を Container Apps に直接マウントできない制約は残るものの、バックアップ間隔を 1 時間程度に抑えれば実運用への影響は限定的だと判断しています。
権限管理
現状ではこのエージェントをSlack経由で誰でも利用することができます。 そのため誰でもエージェントに接続されているツールを利用することができてしまいます。 多数のユーザーがいるSlackチャンネルで利用する場合、権限管理をしっかりと行う必要があります。 ユーザーによる利用できるMCP Serverの制限を行う方法は、今回追加した動的にMCP Serverを追加する機能とDBの機能を組み合わせることで解決できると考えています。 あらかじめSlackのユーザー情報と使用させたいMCP Serverの対応表をDBに持っておき、Slackでメンションしたユーザーの情報を元に、DBからMCP Serverの情報を取得し、MCP Serverを動的に追加することで、エージェント側ではなく、その上位のシステム側で権限管理を行うことができるようになります。 ただし、今回追加したログ閲覧とメモリー機能でバイパスすることは可能なので、利便性とセキュリティのトレードオフを考慮する必要があります。
コストとパフォーマンス
0.5 vCPU・1 GiB を Replica 1 で常時稼働させると月額は約 1 万円に達します。 コールドスタートを許容できる時間帯が事前に読める場合は Replica 0 に設定し、外部ジョブから 1 分間隔でヘルスチェックを投げて必要なタイミングだけウォームアップする案が最も現実的だと考えています。
ランダムネスの入れ方
プロンプトで「たまにOOして」と指定しても、そのプロンプトを利用するエージェントは100%か0%の確率でしかOOを実行してくれないことが多いです。 おそらくセッションを跨いだ情報の共有ができていないため、頻度を調整することができないのだと思います。 セッション開始時にサーバー側で乱数を生成し、その結果を DB に保存してセッション単位で振る舞いを切り替える方式を検証中です。
まとめ
実運用で浮き彫りになった課題を 設計と運用の両面から改善し、使い勝手を向上させました。 今回分かったことは、エージェント側に全てを任せるのではなく、システム側でできることはシステム側でやる方が良いということです。 エージェントはどうしても再現性が低くなってしまうので、システム側で確実に実行されるように設計することが重要だと思いました。 今後も運用を続けながら、さらなる改善を目指していきます。
Obsidianの可能性と限界
はじめに
生成AI（LLM）の普及により、私たちの文書管理の考え方は大きく変わりつつあります。 単に「どこに保存するか」だけでなく、「どの形式で記録し、AIとどう連携させるか」が新たな重要課題となっています。 本稿では、まずMarkdownとAIの親和性について解説し、その上でObsidianというMarkdownベースのノートアプリの長所・短所を整理します。 さらにVSCode, Notion, Google Document、そして私自身の日常的な活用方法を紹介することで、AI時代の文書管理の一助となれば幸いです。
MarkdownとAIの相性の良さ
MarkdownとAIは以下の5点で相性が良いと考えています。
- 高い人間可読性: 非エンジニアを含むすべての人間にとって読みやすい
- 低い人間学習コスト: 表記法がシンプルなので非エンジニアにとっても学習しやすい
- 双方向の編集容易性: 人間とAIの両方が編集しやすい
- 低コスト: プレーンテキストベースでAI処理の料金が安くなる
- データポータビリティ: 異なるサービス間でデータを移動しやすい
主観でプレーンテキスト、HTML、PDF/docx、Markdownの比較表を作りました。
| 形式 | 編集容易性 | 表現力 | AI解析容易性 | 特徴 |
|---|---|---|---|---|
プレーンテキスト(.txt) |
◎ | △ | ◎ | 表やリンク表現が弱い |
| HTML | △ | ◎ | ◎ | 構造が明示的だが人手編集が困難 |
| PDF/docx | △ | ◎ | △ | バイナリ/複雑構造で専用ソフト必須 |
| Markdown | ◎ | ○ | ◎ | テキスト＋軽量タグの最適バランス |
Markdownの具体的なメリットはいくつかあります。
- 行単位で全て可読：段落やリストが改行で分離されており、AIが構造を抽出しやすい
- 装飾の「ゆらぎ」が小さい：
# 見出しや**強調**など、方言差が限定的（諸説あります） - トークン制限に強い：HTMLやPDFよりトークン数が少なく、API処理コストを抑えられる
- 人間とAIの編集サイクルが効率的：人間がエディタで直接修正→AIに再投入という流れがスムーズ
- RAGとの相性：テキスト抽出ステップを省略でき、実装がシンプル
一方、他の形式にはそれぞれ以下のような制約があります。txt形式は、すべてが同じサイズの文字で表現され、表もアスキーアートで表現する必要があるため読みにくくなります。 HTML形式は、タグで情報の意味を明示できますが、非ソフトウェアエンジニアが直接編集するには専門知識が必要です。 PDF/docx形式は読むのは容易ですが、編集には専用ソフトウェアが必要で、実装によってレンダリング品質がばらつく問題があります（例：Libre OfficeでのdocxやブラウザでのPDF編集は問題が多い）。 また高品質なドキュメント作成には有料ソフトウェア（Adobe AcrobatやMicrosoft Office 365など）が必要になることも多いです。
Obsidianの概要
Obsidian は、ローカルフォルダ（Vault）に純粋な Markdownファイルを保存し、ノート間を [[内部リンク]] で結び付けるノートアプリです。
リンクは双方向で管理され、グラフビューによってノート同士の関係を視覚化できます。
加えて、コミュニティ製を中心に数千のプラグインが公開されており、AI 要約やタスク管理、PDF アノテーションなど機能拡張も比較的簡単です。
外出先でも使える公式モバイルアプリがあり、Obsidian Sync（有料）を使うか、iCloud / Dropbox / Git など好みの方法で同期できます。
Obsidianの強みを発揮する場面
元来Obsidianの強みは以下の3点だと考えています。 - オフラインでも作業ができる: ローカルにデータがあるのでネットが不安定でも全文編集が可能 - 思考をリンクで整理したい: 階層よりもネットワーク構造で発想を広げる Zettelkasten 型の整理に適している - データのポータビリティがある: ローカルにMarkdownファイルがあるため、Obsidianを使うのをやめても手元にMarkdownファイルが残る
つまりObsidianは、データをMarkdownファイルとしてローカルに保存し、その上にリッチなMarkdownレンダラーやプラグインシステムを載せているアプリという解釈が適切でしょう。
そして昨今のAIツールの発展に伴い、ObsidianとAIツールの相性も強みとして挙げられるようになりました。 ObsidianとAIツールの相性の良さは主に次の3点だと考えています。
- Markdownベースのデータ保存: Obsidianで作成したMarkdownファイルをそのまま他のAIツールに入力できる
- AIツール連携プラグイン: Obsidian MCP Serverなどのプラグインにより、MCP Host（Claude DesktopやClineなど）からObsidianのファイルを読み書きできる
- 外部AIエディタとの互換性: Obsidianで作成したファイルをCursorなどの外部AIツールで直接編集できる
どの点に関してもObsidianが特別優れているという訳ではありません。 元来のObsidianの強みに加えて、Obsidianのプロダクトの設計がAIツールと相性が良かったということだと考えています。 特に3点目に関しては、ファイルが単一のディレクトリ下に集まっていることが本質です。
ソフトウェアエンジニアであれば VS Code に Markdown 拡張を複数入れることで、プレビュー・自動リンク・PlantUML 生成など Obsidian に近い作業環境を再現できます。 ただ VS Code は設定が煩雑でモバイルアプリも実質的に存在しません。「導入の簡単さ」と「モバイルまで同じ体験」を求める人にとって、Obsidian が好まれるのは自然と言えます。
なお、上記の特性を組み合わせて、私はObsidianのデータをRAGに取り込み、MCPでAIから呼び出すツールを作成しました。 興味のある方は以下の記事もご参照ください。
共同編集に向かないObsidian
Obsidianは決して万能ではないです。 Obsidianはあくまで1人のユーザーが複数のデバイスで利用することを前提にして開発されており、単一のドキュメントを複数人で共同編集するといった作業には向いていません。 Obsidianは標準では、同時編集機能、バージョン管理機能、提案機能、コメント機能、read-only機能といった機能が提供されていません。 GitとGitHubを使えばバージョン管理やコメント機能は実現できはするのですが、非ソフトウェアエンジニアが利用するのは難易度が高いという問題があります。
共同編集に使えるNotionとGoogle Document
同じくMarkdown記法を受け付けるNotionやGoogle Documentは共同編集が前提にプロダクトが設計されています。 組織で文章を管理するにはNotionやGoogle Documentの方が向いているのは明らかです。
一方で、NotionはNotion内で、Google DocumentはGoogle Workspace内で作業を完結するという設計思想を持つため、外部ツールとの連携には課題があります。 ユーザーが好むAIツールでそれらのデータを活用したい場合に制約が生じるのです。
両製品はインポート・エクスポート、コピー＆ペーストをサポートしているため、外部ツールにデータを渡すこと自体は可能です。 しかし、この入出力プロセスは人間が手動で行う必要があり、効率的とは言えません。 自動化の仕組みを構築するのも容易ではありません。
例えばNotionでユーザーの好みのLLMツールを利用するには、Notion APIを活用して変更があったファイルをMarkdownで書き出し、それを外部ツールで編集した後、再びNotion API経由で書き込むという複雑な流れを実装する必要があります。 技術的には可能ですが、かなり手間のかかる構成になるでしょう。 Notion AI自体を使う場合は特別なセットアップは不要ですが、その分ユーザーのLLMツール選択の自由度は限られます。
Google Workspace上のGoogle Documentは、APIを通じて直接読み書きが可能です。Google WorkspaceのGeminiはマルチモーダルな性能を持ち、文章、PDF、画像でコンテキストを渡し、Canvas形式で出力させ、そのままGoogle Document形式で保存できるため、業務において非常に有用です。 ただし、ドキュメント間の関係性を視覚的に示す機能は限定的というデメリットがあります。
個人的Obsidian, Notion, Google Documentの使い分け
私の場合、以前は思いついたことをまずApple Memoに書き、ある程度書きたまったらPCのObsidianに移行するという運用をしていました。 個人的な考えや日記、ブログのネタ帳、ブログの下書きなどはObsidianにまとめていました。 Apple Memoはアプリの起動が速く、iOS、macOS間の同期も容易というメリットがありましたが、独自のリッチテキスト形式しか利用できず、Markdown形式に対応していないという欠点がありました。 最近Obsidian Syncを契約してからは、Apple Memoは使わなくなり、直接Obsidianに記録するようになりました。 一方、Notionは主に旅行の計画を立てる際に利用しています。様々なメディアを貼り付けられる点、複数人で共有できる点、階層構造で情報を整理しやすい点、スケジュール管理機能などが旅行計画に適しているためです。 Google Documentは、不特定多数の人にドキュメントを共有する必要がある場合に利用しています。
まとめ
本稿では、AI時代における効率的な文書管理について、特にMarkdownとObsidianに焦点を当てて検討しました。Markdownは人間とAIの双方が扱いやすく、データポータビリティにも優れているため、現代の文書形式として優位性があります。
ObsidianはそのようなMarkdownを基盤としたノートアプリケーションとして、オフライン作業の確実性、思考のネットワーク的整理、データのポータビリティという3つの強みを持っています。 さらに最近では様々なAIツールとの連携も容易になり、個人の知識管理ツールとしての価値が高まっています。
一方で全てのシーンにObsidianが適しているわけではありません。 共同編集が必要な場面ではNotionやGoogle Documentの方が適しており、用途に応じた使い分けが重要です。 私自身も用途によってこれらのツールを使い分けています。
ObsidianをQdrantに入れてMCP Serverで引き出す仕組みを作った
背景
- Obsidianには技術メモ、日記、日々の考えを記したドキュメントが200ほどある
- 会社の目標設定シートなどObsidianからいい感じに私の個人的目標や挑戦したいことなどを引き出せる環境を作るのを目指す
構成
以下のような構成で実現しています Index作成時
sequenceDiagram
participant Obsidian
participant LlamaIndex
participant Qdrant as Qdrant Server (Docker)
Obsidian->>LlamaIndex: Markdownドキュメント読み込み
LlamaIndex->>Qdrant: ベクトル化されたチャンクをアップロード
LLMのクエリ送信時
sequenceDiagram
participant LLM
participant MCP_Qdrant as mcp-server-qdrant
participant Qdrant as Qdrant Server (Docker)
participant MCP_Obsidian as Obsidian MCP Server
LLM-->>MCP_Qdrant: クエリ送信
MCP_Qdrant-->>Qdrant: 類似ベクトル検索
Qdrant-->>MCP_Qdrant: 該当チャンクとメタ情報返却
MCP_Qdrant-->>LLM: マッチ結果返却
LLM-->>MCP_Obsidian: ドキュメント全体取得（該当パスから）
MCP_Obsidian->>LLM: ドキュメント全体の返却
使用したツール
- Llama Index: ObsidianをVector DBに入れるためな仕組み
- Qdrant: Obsidianのデータを格納するVector DB
- mcp-server-qdrant: LLMからMCP経由でQdrantの情報を呼び出す仕組み
- MCP server for Obsidian: LLMからMCP経由でObsidianの情報を呼び出す仕組み
構成の理由 最初の構成でmcp-server-qdrantで情報を引き出せるようになったが、クエリとマッチ度が高いObsidianのファイルの内容をそのままJSON-RPC2.0の中に入れるため、ものすごい勢いでClaude Desktopのコンテキストを消費します。 3回のQdrant ServerのリクエストでClaude Desktopのレートリミットに引っかかりました。 そのためmcp-server-qdrantは、クエリに合致するドキュメントのメタデータの取得に特化させ、Obsidian MCP Server側でドキュメント全体を取得するように変更しました。 これによりmcp-server-qdrantでコンテンツの意味検索→Obsidian MCP Serverでドキュメントを丸々取得の2段階アプローチで組んだことでコンテキストの使いすぎを防いでいます。 MCP Serverを2つ繋いでいるので、この使い分けをするためにはしっかりとプロンプトを書く必要があります。
作成したソフトウェア
Llama IndexとQdrant Serverのスクリプトが入っているレポジトリ github.com
mcp-server-qdrantに後述するいくつかの修正を加えた github.com
結果
あらかじめ個人的に書き溜めておいたObsidianのドキュメントを元に、目標設定テンプレートを埋めることができました。 （個人情報がかなり入っているので、ここのセクションは詳細に書かないです）
そのほか
最近Obsidian Syncを契約し始めたのですがかなり快適でおすすめです。 今までアプリの起動速度・メモを書き始めるまでの時間が短いことと同期の簡便さでApple純正のメモ帳を使っていたが、独自のリッチテキストでMarkdownが使えないのが難点でした。 Obsidian SyncはApple純正のメモ帳並みの速度、同期の手軽さ、Markdown記法に対応しています。 月$4〜5でこれが手に入るので、財布に余力がある方はぜひ使ってほしいです。
まとめ
とりあえずObsidianとLLMを繋ぐことができました。 Llama Indexを使うことで簡単にObsidianをVector DBに入れることができました。 また現状は一度のindexingにしか対応していないので、ObsidianをGitHubにPushした際にVector DBを更新する仕組みを導入できないか検討したいです。
