プロダクト概要

制作：ニュータンタンメン（なまわさび） ひとこと：ハッカソンのおともになる、DevEx 向上 MCP ツール。

はじめに

dandan は、雑多なメモを貼るだけで、AI が「やること」を切り出し、偏りのない担当割りをして、 GitHub の Issue 化まで片付けてくれる段取りの相棒です。ハッカソンでもチーム開発でも、 アイデアから実装のあいだに横たわる面倒な作業を肩代わりし、開発者が本当にやりたい 「つくること」に集中できるようにします。

わたしたちが感じた課題

ハッカソンでいちばんダルいのは、実はコードではありません。その手前です。

要件をざっくり出すところまでは、勢いでいけます。けれどそこから先―― 「これを Issue に落とさなきゃ」という細かい Issue 化、「誰がやるのか」「粒度はどうするか」 といった要件詰め。この作業が、とにかくつまらない。手が止まり、後回しになり、 気づけば要件はメモのまま腐って、開発時間だけが溶けていきます。

これはやる気の問題ではありません。「メモ」から「タスク」、そして「担当」へと進むあいだの 摩擦が、単純に大きすぎるのです。ならばその摩擦をゼロにしよう――それが dandan の出発点でした。

dandan がすること

使い方はシンプルです。まず、打ち合わせで出た雑多なメモをチャットに貼ります。 すると AI がそれを整形し、意味のある単位に分割し、取り込むべき「気づき」を選別します。 あなたは提示された気づきをその場で採用したり却下したりするだけ。次に、AI が担当を提案し、 誰にどれだけ負荷がかかっているかを偏りとして見せてくれるので、それを確認しながら担当を振ります。 最後にボタンひとつで、GitHub に Issue が立ちます。

これらの操作はすべて、チャットの中に描画される専用パネルの上で完結します。 会話から離れることなく、貼って、選んで、振って、発行する。それだけです。

いちばんの発明――「頭脳」を持たない AI ツール

dandan の最大の特徴は、自前の LLM を持たないことです。

「考える」という頭脳の仕事は、利用者自身の Claude や ChatGPT に委ねます。dandan が担うのは 「捌く」という手の仕事――選別の記録、偏りの計算、GitHub への確実な書き込みです。 この割り切りによって、dandan は API キーも課金も必要としません。自分の AI に MCP サーバーとして 登録するだけで動き、友達に配るのもサーバーひとつ。誰もが自分の使い慣れたモデルを頭脳にできます。

なぜ強いのか――「状態を持つ」ことの価値

プロンプトや Claude Skill は、会話が終わればすべてを忘れてしまいます。dandan はそこが違います。 状態を永続的に持つ。この一点が、使い捨ての自動化を「回すほど成長する段取り基盤」へと変えます。

第一に、状態が残るから、次に活きます。 投げたメモも、採用した気づきも、振った担当も、 その履歴も、すべて残ります。だから次にプロジェクトを回すとき、ゼロからではなく前回の続きから 始められる。使うほどに文脈が濃くなり、段取りの精度が上がっていきます。

第二に、プロジェクト管理者としての知見が育ちます。 貯まるのはタスクだけではありません。 誰が何をどれだけ引き受けてきたかという負荷と偏りのデータが積み上がります。管理者は勘ではなく 根拠で担当を決められるようになり、回すほどに「人を配る目」が鍛えられていく。ツールが成長するだけでなく、 使う人自身の PM スキルも一緒に伸びていくのです。

第三に、UI として扱いやすい。 段取りをテキストの読み書きや JSON の手編集でやるのは苦痛です。 dandan はチャットの中にパネルを描画し、気づきはカードで、負荷は偏りバーで、担当はプルダウンで、 発行はボタンひとつで扱えるようにします。考えるのは AI、決めるのは人。その人の判断を、迷わず、速く、 間違えずに下せるよう UI が支えます。

第四に、チーム全員で共有できます。 状態がサーバー側にあるので、全員が同じ dandan に接続し、 同じ景色を見られます。誰かの気づきも、アサインも、チーム全体の負荷も、みんなに共有される。 個人の Claude の中に閉じてしまう Skill と違い、dandan はチームの共有基盤になれます。しかも参加コストは MCP 登録だけです。

Claude Skills との違い

「それは Claude Skill でもできるのでは」とよく聞かれます。けれど両者は役割が違います。 Skill が担うのは「頭脳の作法」、つまりモデルへの指示です。一方 dandan が担うのは「手」―― データを溜め、偏りを正確に数え、GitHub へ確実に書き込む、決定論的な実行の部分です。

Skill には、この「手」がありません。状態を持てず、会話が終われば忘れ、正確な計算も外部への 確実な書き込みも、プロンプトだけでは担保できません。だから dandan は Skill と競合するのではなく、 むしろ共存します。切り出しや担当提案といった推論は Claude が行い、その判断を受けて永続化・集計・発行を dandan がこなす。頭脳は Claude、手は dandan、という分業です。そして Skill が個人のものである一方、 dandan は状態を共有できる点で、チームの基盤になれます。

技術のかたち

dandan は Go で書かれた MCP サーバーと、埋め込みの HTML/JS による UI で構成されています。 中心にあるのはドメイン型と偏り集計を担う純粋なロジック層で、これは LLM にも DB にも依存しません。 その外側に SQLite による永続化と GitHub 連携があり、いちばん外で MCP のツールと UI 配信を行います。 この一方向の依存関係により、保存先や配信手段を差し替えても中心のロジックは動かさずに済みます。 GitHub トークンは環境変数としてのみ扱い、ログにも DB にも Git にも残しません。

いまの状態

足場づくりと MCP Apps の描画検証は完了し、メモから気づき、アサイン、Issue 化までの一周が すでに動いています。現在は、選別とアサインを合体させた画面、Issue 下書きの編集、スキルマッチの 可視化、タグの正規化といった作り込みを進めています。実機での UI 描画は ChatGPT の MCP Apps で 確認済みです。

おわりに

要件は出せる。でも、Issue 詰めはつまらない。その「つまらない」を肩代わりし、回すほどチームと 一緒に成長していく――それが dandan です。段取りは、AI に任せてしまいましょう。

メンバー

あまこう

困った部分・工夫したポイント

・ツールを名指ししないと呼び出せない MCP はツール名で呼ぶ設計。流れ（順番・導線）をちゃんと設計しないと使いにくい。

・MCP App は iframe から別画面へ遷移できない 「次へ」ボタンが ChatGPT で無反応（sendMessage でモデルに頼んでも効かず）。 そこで画面遷移をやめ、1画面内で display の on/off で見せ隠しする方式に変更。

・ChatGPT が UI やツールを URL 単位でキャッシュする 古い挙動が混じる。毎回コネクタ削除、新 URL で再作成、新チャット、が必須と判明。

・web で作ると LLM の API キーか自作 LLM が必要 MCP App にしたことで、推論をユーザーのサブスク AI（ChatGPT や Claude）に任せられ、追加コストゼロにできた（この構成の狙い）。

・呼び出す順番をミスると普通にバグる 順序依存が強い。セットアップ（メンバーとリポ）を前提フェーズにまとめて、順序ミスを構造的に緩和。

・UI の再生成ボタンが返ってこない MCP クライアント（ChatGPT）に投げても結果通知が来ないことがある。反映ボタンで取りに行く（ポーリングと手動反映）形に。

・最初は Issue の中身が薄かった（タイトルだけで出力が終わっていた） 本文（issue_body）まで生成させたら、その本文に引っ張られてタイトルもいい感じの粒度に改善した。入口の生成を厚くすると出力全体の質が上がる好例。

・store not found で硬く落ちた プラン未確定や古い ID で API が落ちる。空を返す頑丈化で恒久解消。

・（開発時）dev-host を二重起動すると DB が書き込み不能に SQLite の move 誤検知（READONLY_DBMOVED）。起動前に必ず全 kill と1インスタンス運用。

得られた学び

・MCP 経路はバニラ。直チャットが無料で持つ補助知識（システムプロンプトなど）が抜ける。ツール説明に割り方や観点を書いて誘導しないと質が落ちる。

・推論はホスト LLM、dandan はデータと集計と UI の役割分担。入口の切り出しや生成の質が、最終アウトプット（Issue の粒度）まで全部を決める。

・UX の勘所は「UI 内で完結、チャットでツール名を打たせない」。画面遷移に頼らず、1画面でセクションを見せ隠しするのが（MCP の制約下で）確実。

---

とうり

今回のハッカソンでは、チーム「ニュータンタンメン」として「ハッカソンのお供になるDevX向上MCPツール」を開発しました。この開発で私はMCPの理解を深めたり、具体的な設計の提案、デプロイとダッシュボードの実装・構築を行いました。 今回のハッカソンでは、今までしっかり考えたことのなかったMCPについて理解を深めることができました。最初はさまざまな情報が頭の中で絡まっていて、開発も議論も進まなかったのがとても悔しいです。ですが、この知識は今後の開発に非常に生きると思うのでやってよかったとも同時に思います

---

はやと

今日はずっとMCPについて学習していました。

MCPとは、AIが実行できる操作を、人間が定義した確定的な範囲に収めるための仕組みです。AIが内部から叩ける「選択肢」として機能を作り、MCPサーバーとして提供します。サーバーが外に見せる要素は主に3つあり、Tools（AIの解釈が絡まない確定的な実行）、Resources（AIが読み取る対象。情報源）、Promptsに分かれます。この分類の軸はAIの解釈が絡むか絡まないかで、Toolsは解釈を挟まず確定的に動く部分、という整理ができました。 一番苦戦したのは、「MCPはAIが実行する方法（例：GitHubのissueを立てる）を提供するだけ」だという点です。個々の手は用意できても、それらをどう繋いで一連のPMとして動かすかをどこに書くべきかで迷走しました。また、今回はツールチェーン？として一連の流れを一つのプロダクトとして作成しようとしていたので、プロンプトなのか、オーケストレーションの仕組みなのか、Skillなのか、ツールのdescriptionに順序を指定しておくのか、ここが長く整理できませんでした。 現時点での結論として、繋ぎ方はツールのdescriptionには書かない、という原則にたどり着きました。descriptionにはそのツールが単体で何をする手かだけを書き、次に何を叩くべきかという順序は書かない。繋ぐ順序と判断基準はSkillに置いたりプロンプトに支持を上手に与え、繋ぐための材料はツールの返り値で受け渡す。そして順序を実際に実行するのはツールでもサーバーでもなく、ホスト側で走るAI側である、という層の分離が見えてきました。 mcpを作成するにあたり、他のメンバーは積極的に手を動かすことができていたのですが、自分はこのmcpツールの内容的にskillsで作ればそのままいいものができるがなぜこのmcpツールじゃないといけないのか、という疑問から入り、aiについての概要、また、それらの動作原理など、なぜを突き詰めていってからプロダクトの制作指針を理解できたうえで開発に携わりたかったのですが、概念の理解にかなり時間を取られて、開発そのものにはあまり貢献できませんでした。さーせん。ただ、この土台が固まったことで、方針がかたまり実装を進められそうです。