1. CAP Portalとは何か

2026年8月7日、Intersectは Constitutional Amendment Portal（CAP Portal） をalpha公開した。

CAP Portalは単なるCardano Constitutionの閲覧サイトではない。

その本質は、

Cardano憲法について、問題を発見し、改正文を起草し、コミュニティで議論・修正したうえで、オンチェーンGovernance Actionへつなげるための「熟議レイヤー」

にある。

Cardanoにはすでに、DRep、SPO、Constitutional Committee（CC）によるオンチェーンGovernanceが存在する。しかし、これまで「憲法のどこを、なぜ、どのように変更すべきか」を継続的かつ構造化して議論する共通の場所が不足していた。

CAP Portalはこの空白を埋めようとしている。

2. なぜCAPが必要だったのか

Cardano Constitutionは、永久に固定された文書として設計されているわけではない。

実際のGovernanceを運用すれば、曖昧な表現、想定していなかった問題、新しい技術や社会状況との不整合が見つかる可能性がある。

しかし従来は、

1. 誰かが憲法上の問題を発見する
2. Forum、SNS、会議などで議論する
3. 議論が複数の場所へ分散する
4. 具体的な改正文まで到達しない
5. 議論が消えていく

という問題があった。

CAP Portalはこれを、

問題発見 → CIS → コミュニティ議論 → CAP → 改正文の洗練 → オンチェーンGovernance

という連続したプロセスに変えようとしている。

3. CISとCAP

CAP Portalには、特に重要な2種類の提案形式がある。

種類 正式名称 役割 ----------------------- ----------------------- -------------------------------------- CIS Constitutional Issue 憲法上の問題・曖昧さ・欠落を提示する Statement

CAP Constitutional 具体的な憲法改正文を提示する Amendment Proposal

CIS：問題だけでも提起できる

憲法を読んで、

「この条文は曖昧ではないか」

と気づいても、適切な修正文をすぐ書けるとは限らない。

そこでCISでは、完成した解決策がなくても問題そのものをコミュニティへ提示できる。

これは参加障壁を下げる重要な設計である。

CAP：具体的な改正文を提示する

CAPでは、憲法の特定部分を指定して、

• 現行文を置き換える
• 新しい文章を追加する
• 変更理由を説明する

ことができる。

つまり、CISが「Issue」なら、CAPは具体的な「修正案」である。

4. 憲法本文と改正ツールが一体化している

CAP Portalでは、Cardano Constitutionを条文ごとに読み、その場で変更対象を指定できる。

概念的には、

Constitution → 対象文章を選択 → Replace / Add → 理由を書く → Preview → CAP公開

という流れになる。

これは重要である。

SNSやForumで「Article ○○のあの文章」と議論するのではなく、議論対象となる憲法本文と提案を直接結び付けられるからだ。

法令・規約・憲法の共同編集システムとして合理的な構造である。

5. CIP-30 WalletがIdentityになる

CAP Portalでは、CIP-30互換Cardano Walletを接続して参加する。

メールアドレス、パスワードによる通常のWebアカウントではなく、stake addressを参加主体のIdentityとして利用する設計である。

これは、

Web2 Identity → Cardano Stake Identity

への移行ともいえる。

Cardano上の主体とGovernance上の発言を結び付けやすい一方、stake addressと政治的・Governance上の発言履歴が関連付けられる可能性もある。

したがって将来的には、透明性とpseudonymous privacyのバランスも検討課題となる。

なお、stake addressによる識別はKYCによる実名本人確認とは異なる。

6. CAPはGovernance Actionそのものではない

ここは非常に重要である。

CAPを公開しただけでCardano Constitutionが変更されるわけではない。

CAP Portalは基本的にオンチェーンGovernanceより前に存在する、

pre-governance / deliberation layer

である。

CAP Portal On-chain Governance ---------------------- ----------------------------- 問題発見 正式なGovernance Action CIS 問題の制度化 CAP Constitution Update案の成熟 Community discussion 投票 修正・洗練 Ratification Consensus building Protocol上の決定

つまりCAPの役割は、投票そのものではなく、投票に値する提案をコミュニティで作ることにある。

7. 「誰が決めるか」から「何を議題にするか」へ

CardanoのオンチェーンGovernanceは、DRep、SPO、CCなどによって「誰が意思決定に参加するか」を分散化してきた。

CAP Portalがさらに踏み込むのは、

何をGovernanceの議題にするのか

というAgenda Settingの領域である。

仮に、

中央組織 → 議題を決定 → DRepへ提示 → DRepが投票

という構造なら、投票者が分散していても議題設定権は中央集権的なままである。

CAPが機能すれば、

Community → CIS → CAP → Community deliberation → Governance Action → DRep/SPO/CC

という経路が成立する可能性がある。

これは「誰がYES/NOを決めるか」だけでなく、「何についてYES/NOを問うのか」まで分散する試みと評価できる。

8. DRepにとっての意味

DRepにとってCAPは重要である。

従来のDRep活動は、

Governance Actionが提出される → 調査する → YES / NO / Abstainを判断する → 理由を説明する

というReactiveな活動になりやすかった。

CAPが定着すると、

CISで問題を認識 → CAP段階で議論 → 文案を改善 → Governance Action → 最終投票

という、より上流からの参加が可能になる。

つまりDRepは、

Reactive DRepからProactive DRepへ

移行できる。

しかも完成した改正文を作れなくても、CISとして制度上の問題を提示できるため、個人DRepでも参加しやすい。

9. Constitutional Committeeとの違い

CCとCAPは役割の方向が異なる。

CC - 提出されたGovernance ActionがConstitutionに適合しているかを判断する。

CAP - Constitutionそのものに問題がないかを問い、必要なら変更案を育てる。

簡略化すると、

CC = 憲法を適用する側

CAP = 憲法を進化させるための入口

である。

ただし、実際の憲法変更には最終的にオンチェーンGovernance Actionと所定の承認プロセスが必要となる。

10. GitHub型Governanceとして考える

CAP Portalはソフトウェア開発に例えると理解しやすい。

Software development Cardano Constitution ---------------------- ------------------------ Issue CIS Pull Request CAP Code review Community consultation Revision CAP refinement Merge decision On-chain governance Release Updated Constitution

この意味でCardano Constitutionは、「完成して固定された石碑」ではなく、

version管理されながら改善されるGovernance OS

に近づいている。

これはCAP Portalの非常に重要な思想的意味である。

11. CAP Portalのリスク

オープンなPortalを作れば、自動的に分散型Governanceが完成するわけではない。

Scenario 状態 評価 ----------------------- ----------------------------------------- --------------------------------- S5 最良 CAPが標準的な憲法改正プロセスとして定着 継続的な憲法改善が制度化

S4 DRep・SPO・CC・Communityが積極利用 Governance Action前の熟議が改善

S3 一部コミュニティのみ利用 有用だが影響は限定的

S2 提案が大量発生しNoise化 Spam・議論疲労・重要案件の埋没

S1 最悪 有力組織・大規模DRep等がAgenda CAP自体が新たな権力集中点になる Settingを支配

今後重要なのは、

• 誰がCIS/CAPを提出しているか
• 誰が議論へ参加しているか
• どの提案が注目されるか
• どのCAPがGovernance Actionへ進むか
• 特定組織・大規模DRepへ議題設定力が集中していないか

を観察することである。

これは将来的にCardano Governance decentralizationを測定する新しい指標になり得る。

12. Cardano Governanceを4層で見る

CAP Portalの登場によって、Cardano Governanceは次の4層として理解すると分かりやすい。

Layer 1：Constitution

「何を守るのか」

Cardano Governanceの価値、原則、Guardrailsを規定する。

Layer 2：Deliberation / Agenda Setting

「何を変えるのか」

CIS・CAPを使って問題を発見し、改正案を議論・洗練する。

Layer 3：Voting

「採用するのか」

DRep、SPO、CCなどがGovernance Actionを審査・投票する。

Layer 4：Execution

「決定をどう実行するのか」

Protocol、Treasury、Governance上の決定として実装される。

これまで目立っていたのはLayer 3のオンチェーン投票だった。

CAP Portalは、その前にある Layer 2を制度化する試み と位置付けられる。

13. CGTA評価

CAP Portalのalpha公開は、Cardano Governanceにとって重要な進展と評価できる。

ただし、現時点ではalphaであり、「Cardanoの憲法改正制度が完成した」と評価するのは早い。

より正確には、

Cardanoが、憲法改正のオンチェーン決定機構だけでなく、その前段階にある問題発見・起草・熟議・合意形成まで制度化し始めた。

という段階である。

Cardanoが分散化しようとしている対象は、単に「投票権」ではなくなりつつある。

議題を作る権利、制度を設計する権利、そして憲法そのものを改善する権利までコミュニティへ開こうとしている。

CAP Portalが本当に成功するかどうかは、Portalの技術的完成度だけでは決まらない。

最終的には、

Community → CIS → CAP → 熟議 → Governance Action → Ratification

という経路が実際に使われ、特定主体へAgenda Setting powerが集中せず、多様な参加者が制度形成に関われるかで評価されるべきである。

DRepにとっても、これは単なる新しいWebサイトではない。

「提出されたGovernance Actionを評価するDRep」から、「Governance Actionになる前の制度形成にも参加するDRep」へ進むための入口になり得る。

参考資料・Fact Check

• Intersect, **The Constitutional Amendment Portal: giving Cardano's

Constitution a way to grow**, 2026-08-07.

• Intersect Knowledge Base, Cardano Constitution.
• Intersect Knowledge Base, Governance Action.
• Intersect Knowledge Base, Constitutional Committee.
• Intersect Civics Committee / Constitutional Amendments Working

Group関連資料.

• CAP Portal: https://cap.intersectmbo.org/
• Cardano Epoch表：ユーザー提供

Cardano_epoch.pdf。2026-08-11はEpoch 648（2026-08-08 06:44:51 JST〜2026-08-13 06:44:51 JST）。

確認上の注意

CAP Portalは現在alpha段階であり、最終仕様、正式運用時のワークフロー、CAPからオンチェーンGovernance Actionへ移行する際の詳細な責任主体・条件については、今後変更される可能性がある。

【深掘り】CAP Portal：4つのサンプル提案と議論まとめ

0. この記事の位置づけ

2026年8月にalpha公開された Constitutional Amendment Portal（CAP Portal） では、Cardano Constitutionに対する問題提起や改正提案が、CISまたはCAPとして投稿され始めている。

今回確認した4つのサンプルは、CAP Portalの初期運用を理解するうえで非常に良い教材である。

対象は次の4件である。

これら4件は、単独でも重要だが、まとめて見るとCardano Governanceの今後の争点がかなり明確になる。

中心テーマは、次の3つである。

1. 憲法改正案の作り方
2. Treasury支出の統制方法
3. DRepやコミュニティがどの段階で関与するべきか

1. CIS：The “Bundling” problem

1.1 提案の種類

これはCAPではなく、CIS（Constitutional Issue Statement） である。

つまり、完成した憲法改正文を提示するものではなく、

憲法改正プロセスに存在する可能性のある問題を、コミュニティで議論するための問題提起

である。

1.2 問題の本質

Bundlingとは、構造的に異なる複数の変更を1つの改正案にまとめることである。

たとえば、1つの改正案の中に、

• 文法修正
• 定義変更
• 財務ルール変更
• 委員会権限の調整
• 非拘束的文言の削除

が混在している場合、投票者はそれぞれに個別の意思表示ができない。

つまり、

Aには賛成だが、Bには反対

という判断ができず、1つのYES/NOに圧縮されてしまう。

1.3 このCISが指摘する4つの問題

このCISの特徴は、悪意ある提案者を想定していない点である。Bundlingは、締切、作業効率、文書整理の都合でも自然に起こり得る。だからこそ、手続上のfail-stateとして早めに名前を付ける必要がある、という主張である。

1.4 コメント議論

Thomasは、Bundlingは制度が強制しているものではなく、提案者が分けて提出することもできると指摘した。

これに対しStygは、重要なのは「分けられるか」ではなく、

分けるかどうかの権限が提案者側にあり、投票者側にはbundleを分解する権限がない

ことだと応答した。

さらにStygは、CISは解決策を書く場所ではなく、問題をコミュニティで確認する場所であるとして、自身のCISを「problem-only」に修正する意向を示した。

1.5 DRep視点での評価

このCISは、CAP Portalの最初期サンプルとして非常に重要である。

理由は、Cardano Governanceにおいて、投票権の分散だけでなく、

どの単位で投票させるのか

が大きな制度設計問題であることを示しているからである。

DRepとしては、今後の憲法改正案を見る際に、

• 変更内容が単一主題か
• 異なる論点が抱き合わせになっていないか
• 賛否を分けるべき項目が1つの投票に束ねられていないか

を確認する必要がある。

2. CAP：Evolve the Net Change Limit into a Strategic Spending Plan

2.1 提案の種類

これはCISではなく、具体的な憲法改正文を含むCAP（Constitutional Amendment Proposal）である。

2.2 提案の本質

現行のNet Change Limit（NCL）は、一定期間にCardano Treasuryから流出してよい最大額を定める仕組みである。

Thomasの提案は、このNCLを単なる支出上限ではなく、

総額上限 + 高レベル予算カテゴリ別配分

を含む、戦略的支出計画へ拡張しようとするものである。

2.3 提案の3本柱

つまりThomas案は、NCLを、

How much?

だけでなく、

What for?

にも答える制度に変えようとしている。

2.4 wakuda氏の反論

wakuda氏は、NCLとBudgetは明確に分けるべきだと反論した。

整理すると次のようになる。

wakuda氏の懸念は、Thomas案では1つのGovernance Actionに次の3つがまとまってしまう点である。

1. 財政規律としてのNCL
2. 期間中の総予算
3. 高レベルカテゴリ別配分

これは、前述のBundling problemとも関係する。

2.5 Thomasの再整理

Thomasは、NCLとBudgetを完全に混同しているわけではないと説明している。

Thomasの意図は、個別line itemをNCLに入れることではなく、戦略的な「what for」を高レベルのbucketとしてコミュニティで共有することにある。

つまり、Thomas案は、

個別案件は柔軟に残しつつ、支出の大方向だけはNCL段階で承認したい

という立場である。

2.6 DRep視点での評価

この提案の問題意識は妥当である。Treasury支出が個別Withdrawalの積み上げだけになると、Cardano全体として何に投資しているのかが見えにくくなる。

一方で、NCLとBudgetを一体化しすぎると、財政上限、支出計画、カテゴリ配分が1つの投票に束ねられる。

DRep視点では、より健全な設計は次の3層である。

したがって、方向性としては賛成寄りだが、NCLとBudgetの手続的分離は重要である。

3. CAP：Remove Article II section 7.4

3.1 提案の種類

これはArticle II Section 7.4周辺の文言を削除・置換しようとするCAPである。

3.2 提案の本質

この提案は、Treasury Withdrawalに義務付けられている次の要素を削除しようとしている。

• 定期的な独立監査の費用配分
• oversight metricsの実装費用配分

一方で、次の要素は維持される。

• administratorの指定
• 資金使用とdeliverables達成の監視
• community audit可能な分別口座
• SPO委任禁止
• predefined abstain voting optionへの委任

つまり、監査・監督の仕組み全体を消す提案ではなく、独立監査費用とoversight metrics義務を外す提案である。

3.3 Michele氏の問題意識

Michele氏は、Article II Section 7.4の範囲が広すぎ、解釈に委ねられすぎていると主張している。

その結果、Constitutional Committee membersによる権限濫用、または過剰な官僚制が生じているという問題意識である。

つまり、

監査やoversight metricsの要求が広すぎるため、CC等が過度に介入できる

という立場である。

3.4 この提案のメリット

3.5 この提案のリスク

この提案は「過剰監督」を減らす方向だが、削除が大きすぎると「説明責任」まで弱める可能性がある。

3.6 ThomasのEditor note

Thomasは、このCAPがCAP-1、すなわち Require Milestone-Based Treasury Disbursement and Return of Undistributed Funds と衝突する可能性を指摘している。

理由は、両者が同じArticle II Section 7の近接部分を変更するからである。

これは、CAP Portal上で非常に重要な実例である。

個々のCAPは現行憲法に対するdiffとして作成されるが、CAP同士の競合・依存関係は別途検出・調整が必要になる。

4. CAP：Require Milestone-Based Treasury Disbursement and Return of Undistributed Funds

4.1 提案の種類

これはTreasury Withdrawalの資金管理を強化するCAPである。

4.2 提案の本質

この提案は、

Cardano Treasuryから一括でADAを出して終わりにするのではなく、成果物ごとのマイルストーン達成に応じて段階的に支払い、未使用・未配分のADAはTreasuryへ返還させる

というルールを憲法に追加しようとしている。

4.3 提案されている最低基準

この提案は、TreasuryからADAが出た後の資金統制を明確化するものである。

4.4 前払い例外

このCAPは、すべての前払いを禁止しているわけではない。

ライセンス費用、会場予約、リテイナー、商業統合など、実務上どうしても前払いが必要な費用はあり得る。

そのため、Governance Action内で必要性を具体的に説明した場合に限り、前払いを認める構造になっている。

4.5 メリット

4.6 リスク

この提案は、公共資金管理としては妥当だが、全案件に同じ重さで適用すると官僚化する可能性がある。

5. 4提案の比較表

6. 4提案の関係図

Bundling problem
  └─ すべてのCAPに関係する「投票単位」の問題
        │
        ├─ NCL Strategic Spending Plan
        │    └─ NCL・Budget・カテゴリ配分・閾値・ロック期間を1つにまとめる懸念
        │
        ├─ Remove Article II section 7.4
        │    └─ Treasury監査義務を軽減する方向
        │
        └─ Milestone-Based Disbursement
             └─ Treasury支払い統制を強化する方向

さらに、Remove Article II section 7.4とMilestone-Based Disbursementは、同じArticle II Section 7を変更するため、CAP同士の競合関係にある。

CAP-2: clauses 4–6を置換
CAP-1: clause 6直後に新文を挿入
        ↓
両方が通ると適用順序によって条文整合性が問題化

これはCAP Portalのalpha段階で見えた重要な制度課題である。

7. 5段階シナリオ分析

8. DRep BWtakeとしての実務的見方

DRepとして見る場合、4提案は次のように整理できる。

特に重要なのは、Treasury Governanceを次の3層で見ることである。

この3層を混同すると、NCLが重くなりすぎたり、Budgetが曖昧になったり、Withdrawalの説明責任が弱くなったりする。

9. CGTA総合評価

この4つのサンプルから見えるCAP Portalの意義は大きい。

CAP Portalは、単に憲法改正案を投稿する場所ではない。

むしろ、

憲法改正案の単位、相互依存、Treasury統制、DRep判断、コミュニティ熟議を可視化する実験場

になっている。

今回の4件だけでも、次の課題が明確になった。

1. Bundlingをどう防ぐか
2. CAP同士の競合をどう検出するか
3. NCLとBudgetをどう分けるか
4. Treasury支出にどこまで監査・報告・返還義務を課すか
5. 小規模案件を過剰な官僚制からどう守るか
6. 大型案件の説明責任をどう担保するか

最も望ましい方向は、次のような制度設計である。

CIS
  └─ 問題を定義する

CAP
  └─ 解決策を提示する

Conflict detection
  └─ 他CAPとの衝突を可視化する

Single-subject discipline
  └─ 抱き合わせを避ける

NCL / Budget / Withdrawal
  └─ 財政上限・戦略配分・個別実行を分離する

Proportional accountability
  └─ 案件規模とリスクに応じて監査・報告・返還義務を調整する

DRepとしては、各提案に単純にYES/NOを付ける前に、

• その提案はCIS向きかCAP向きか
• 単一主題か
• 他のCAPと衝突していないか
• 財政上限、予算配分、個別支出が混ざっていないか
• 小規模案件と大型案件に同じ重さの義務を課していないか

を確認する必要がある。

10. まとめ

この4つのサンプルは、CAP Portalのalpha版がすでに実質的な熟議を生み始めていることを示している。

特に、Bundling problemは、今後すべての憲法改正案を見る際の基本レンズになる。

NCL Strategic Spending Planは、Cardano Treasuryを戦略的に運用する必要性を示している。

Remove Article II section 7.4は、監査・監督が過剰な裁量や官僚制につながる危険を示している。

Milestone-Based Disbursementは、Treasuryから出たADAを成果・報告・返還と結び付ける必要性を示している。

この4つを合わせて見ると、Cardano Governanceの次の課題は明確である。

Treasuryを戦略的に使う。しかし、説明責任を失わない。 説明責任を強める。しかし、官僚制で提案者を潰さない。 憲法を改正できるようにする。しかし、抱き合わせや競合で投票者の判断を歪めない。

これがCAP Portal初期提案群から見える、Cardano Governanceの本質的な設計課題である。

参考資料・Fact Check

• CAP Portal掲載CIS: The “Bundling” problem, Author: Styg, Submitted: 2026-08-07.
• CAP Portal掲載CAP: Evolve the Net Change Limit into a Strategic Spending Plan, Author: Thomas, Submitted: 2026-08-07.
• CAP Portal掲載CAP: Remove Article II section 7.4, Author: Michele, Submitted: 2026-08-06.
• CAP Portal掲載CAP: Require Milestone-Based Treasury Disbursement and Return of Undistributed Funds, Author: Inputendorsers, Submitted: 2026-08-06.
• 各提案のDiscussion欄におけるThomas、Styg、wakuda、M.Dyamondのコメント。
• Cardano Epoch表：ユーザー提供 Cardano_epoch.pdf。2026-08-11はEpoch 648。

確認上の注意

本まとめは、ユーザー提示資料およびアップロードされたCAP Portal本文・Discussion欄に基づく整理である。CAP Portalはalpha段階であり、提案文、レビュー状態、コメント、Portal仕様は今後変更される可能性がある。

作成日：2026-08-11 JST Cardano Epoch：648