gadak：Jira と Confluence をローカル SQLite mirror にする
多くの team で困るのは、Jira に data がないことではない。Data が network API、paged search、UI filter の奥に閉じ込められていることだ。知りたいことは単純でも、たとえば「どの epic が一番詰まっているか」「最近 reopen され続けている issue はどれか」「あの決定は comment にあったのか wiki にあったのか」を調べようとすると、Jira、Confluence、JQL、REST API script を行ったり来たりする。
今日見るのは midagedev/gadak。発想はかなり素直だ。Jira と Confluence を local SQLite file に同期し、issues、comments、history、wiki pages をまとめて index する。その上で desktop app、browser UI、CLI、SQL、MCP/agent surface から同じ mirror を読む。README で象徴的なのは、JQL には GROUP BY がないが、data が SQLite に入れば「未解決 issue が一番多い epic」は普通の SQL で聞ける、という例だ。
GitHub repository API、README、LICENSE、Languages API、Commits API、Releases API を 2026-08-24 21:07 Asia/Shanghai 時点で確認すると、midagedev/gadak は 24 stars、2 forks。主要言語は Go で、TypeScript、Svelte、Shell などの UI・周辺コードも含む。License は Apache-2.0。Repository created time は 2026-08-04 12:52:06 UTC、latest public push は 2026-08-24 12:56:43 UTC、default branch は main。最新 GitHub Release は v0.17.1、published at 2026-08-23 23:46:18 UTC で、macOS、Linux、Windows 向け binary と checksums が用意されている。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | midagedev/gadak |
| 位置づけ | Jira / Confluence の local SQLite mirror、search、agent query layer |
| Stars | 24 |
| Forks | 2 |
| 主要言語 | Go |
| ライセンス | Apache-2.0 |
| 作成日時 | 2026-08-04 12:52:06 UTC |
| Latest push | 2026-08-24 12:56:43 UTC |
| Default branch | main |
| 最新 Release | v0.17.1、2026-08-23 23:46:18 UTC |
| Install surface | Homebrew、release archive、install script、Docker / source build |
| キーワード | Atlassian、Jira、Confluence、SQLite、local-first、CLI、MCP、full-text search |
Collaboration system を query できる file にする
gadak の core は、もう一つ Jira client を作ることではない。Work system の記録を、直接 query できる local file にすることだ。Connected workspace では Atlassian Cloud に接続し、Jira issues、comments、changelog、Confluence pages などを同期する。Standalone workspace では Atlassian なしで local issue origin として使える。README でも mirror は cache であり、Jira は source of truth のままだと説明されている。Project をやめるなら local directory を消せばよく、remote Jira data は失われない。
この boundary は大事だ。「Jira replacement」は team workflow の移行を求めるので、現実には導入が重い。gadak は横に置く tool だ。Team に Jira を捨てさせるのではなく、既存 system を local に mirror し、その mirror に対して低 latency で組み合わせやすい query surface を作る。
Programmer にとって自然な入口は CLI と SQL だ。README には gadak sql の例があり、gadak issue、gadak search、gadak serve も用意されている。問いは「Jira UI にその filter があるか」ではなく、「SQLite にその column があるか」になる。臨時の調査が、browser 操作より log や database を調べる感覚に近づく。
agent に向いている理由
gadak が MCP や agent surface を掲げているのは、流行語を貼っているだけではない。Agent が苦手なのは、system をまたぎ、page をまたぎ、pagination と UI context に分断される調査だ。Coding agent に「この bug は前にどう議論されたか」と聞いたとき、browser page だけを読むなら cost が高く、context も散らばる。Issue、comment、history、wiki page が local index になっていれば、agent はまず SQL や search で範囲を絞り、必要な record だけを開ける。
これは普通の RAG knowledge base とも少し違う。Jira / Confluence data には強い structure がある。Status、assignee、priority、epic、label、history、comment、page。Vector search だけでは、計算できる情報をかなり落としてしまう。SQLite mirror なら、full-text search と structured query を並べて使える。ある error code を含む comment を見つけ、その後 project、status、epic で aggregate する、といった動きができる。
README では、mirror を読むのは binary call で、具体的な item は gadak://view?issue=... のような link で開けるとも説明されている。これは自前 UI だけを想定した設計ではない。Launcher、script、agent host が横から接続できる。Local tool が CLI、deep link、MCP、SQL を同時に持つと、単体 desktop app より使い道が広い。
改善できそうな場面
一つ目は triage だ。Project manager や engineer が「長く同じ status にいる issue はどれか」を見たいとき、Jira UI だけでは history aggregation が扱いにくい。gadak が changelog を同期していれば、status change time を local query で調べられる。正式な reporting tool の代わりではないが、report がまだない問いに engineer がすぐ答えるには向いている。
二つ目は Jira と Confluence をまたぐ search だ。決定は wiki にあり、実行状態は issue にあり、後の議論は comment にある、という構造は珍しくない。gadak が pages、titles、bodies、comments を同じ search experience に置くなら、「その文章を見た覚えはあるが、どの system か分からない」という摩擦を減らせる。
三つ目は local automation だ。毎週 risk list を作る、担当者がいない high-priority issue を探す、ある epic の未解決項目を agent に渡して implementation suggestion を作らせる。Atlassian API を直接叩いてもできるが、auth、pagination、field mapping、speed を処理する必要がある。gadak が継続更新される local database にしてくれるなら、script 側は SQLite を相手にすればよい。
四つ目は offline または low-latency search だ。README には benchmark があり、local query が REST API より速いことを示しつつ、initial sync と watch tick の cost も書いている。この点は健全だ。Sync cost を払って、日々見る work items の search と aggregation を local に寄せる、という tradeoff だからだ。
設計で気になるところ
一番大事なのは、mirror を唯一の真実にしていないことだ。Connected mode では write operation は origin に通り、その後 mirror が refresh される。Standalone mode では local origin file が durable state になる。この分け方は、「local cache と remote system のどちらが正しいのか」という混乱を減らす。
Install path も現実的だ。macOS では Homebrew cask で desktop app、または CLI only を入れられる。Windows と Linux には release archive があり、install script、Docker、source build の道もある。24 stars の project として、multi-platform binary、checksums、v0.17.1 release まで出ているのは、concept README だけの repository より観察する価値がある。
制限を書いている点もよい。README の feature table では board UI、dashboard、Jira notifications などが scope 外だと明示されている。JQL も documented subset を mapping し、表現できない clause は黙って落とさず拒否するという姿勢だ。この種の mirror tool では、半分だけ正しい結果を返すより、正直に拒否するほうが重要になる。
どう試すか
Atlassian Cloud があるなら、まず critical ではない site や小さな project で試すのがよい。README の CLI path は、install 後に gadak init && gadak sync && gadak serve を実行し、gadak serve が出す local address を開く流れだ。最初から Jira に write back させるより、同期された field、search quality、SQL schema が team data に合うかを確認したい。
Interaction だけ見たいなら、README の demo や standalone workspace から始められる。Standalone mode は Atlassian account が不要で、gadak init --standalone で local workspace を作り、CLI から issue を作れる。Real Jira sync の品質は検証できないが、Web UI、CLI、local file model の感触は早く分かる。
Programmer らしい試し方は、実際の問いを数個 SQL にすることだ。ある epic の unresolved items、直近一週間で reopen された issues、ある keyword が comment に出たのか wiki page に出たのか、特定 assignee の blocker distribution。こういう問いを自然に答えられるかどうかが、UI の見た目よりも workflow に残るかを決める。
Caveats
第一に、project はかなり若い。Repository は 2026-08-04 作成で、現在 24 stars。Release と README は整っているが、0.x 段階なので、team critical workflow にいきなり入れるには早い。
第二に、主な対象は Atlassian Cloud と local workspace だ。Self-hosted Jira、複雑な permission model、大規模 instance、multi-site organization、compliance audit などは別途検証が必要になる。README でも board UI、dashboard、Jira notification inbox など未対応の機能が明示されている。
第三に、mirror は realtime truth ではない。Sync と watch tick に依存し、README も mirror は Jira から one sync interval 遅れると書いている。判断に使うときは、今見ているものが local mirror であり、remote の直近状態そのものではないと理解しておきたい。
第四に、agent integration は慎重に扱うべきだ。Agent が issue や wiki を query できるのは便利だが、comment、transition、assign などの write operation には permission boundary と audit policy が必要になる。gadak が surface を提供していることと、team がすぐ write permission を開けるべきかは別問題だ。
まとめ
midagedev/gadak が面白いのは、「workflow data を query できるか」を UI より先に置いているところだ。Jira と Confluence は source system のまま残し、gadak はそれらを local SQLite に mirror し、CLI、Web UI、SQL、MCP、deep link を同じ file の上に接続する。
まだ新しい project なので、小さく試すのが前提だ。それでも Jira、Confluence、script、agent の間で context を運ぶ時間が多いなら、gadak の方向はかなりはっきりしている。Data をまず local に取り戻し、search、aggregation、audit、automation に使える file にする、という方向だ。