Agent</th>	Perspective</th>	Criteria</th></tr></thead>
MELCHIOR</td>	Scientist</td>	Technical feasibility, efficiency, scalability, quality of evidence</td></tr>
BALTHASAR</td>	Mother</td>	Legal compliance, ethical validity, risk management, impact on the vulnerable</td></tr>
CASPER</td>	Woman</td>	Emotional impact, UX, trend alignment, empathy</td></tr> </tbody></table> This system had one problem: when the vote split 2-to-1, the minority opinion was merely recorded. The dissenter had no chance to rebut the majority. Even if the minority held an important argument, it might never influence the conclusion.</p> Super MAGI with Agent Teams</h2> In February 2026, Claude Code announced "Agent Teams" as a research preview.^{2</a></sup> Previously, sub-agents could only work independently. With Agent Teams, agents can exchange messages directly with each other.</p>} When I saw this feature, I thought, "What happens if MAGI agents debate when they disagree?"</p> In the original MAGI, a 2-to-1 split simply recorded the minority opinion.</p> Original MAGI</strong></p>

Coded Chords - CLI

pCloud DriveのmacOS Tahoe問題

2026-06-27T10:00:00+09:00

Table of Contents</summary> </details>

macOS Tahoe(macOS 26)に上げてから、pCloud Driveが起動するが機能しない状態となりました。やっかいなのは、アプリ単体では済まず、うっかりpCloud Driveを開こうとするとキーボードが効かなくなるなどMac全体が一時的に不安定になる点です。</p>

pCloudとは</h2>
pCloudは、スイスのpCloud AGが提供するクラウドストレージサービスです。買い切りの生涯プランがあること、ファイルを暗号化して預けられること、そしてアカウントを作ると無料枠から使い始められることで知られています。</p>
Macで使う場合、もっとも手軽なのは公式のpCloud Driveアプリです。これはクラウド上のファイルを、ローカルの仮想ドライブ(`~/pCloud Drive</code>)としてマウントして見せてくれます。Finderから普通のフォルダのように開けるので、クラウドを意識せずに使えるのが利点です。</p>`
`一方で、この「仮想ドライブとして見せる」仕組みは、macOSのファイルシステム拡張に依存します。後述するように、ここがOSのアップデートで影響を受けやすい部分でもあります。</p>`

macOS Tahoeでの不具合</h2>
私の環境はApple SiliconのMacで、OSはTahoe(macOS 26)です。アップデート後、pCloud Driveが機能せず、開こうとするとOS全体の挙動が一時的に不安定になりました。</p>
同様の現象が一般に報告されているか調べたところ、Tahoe環境での不具合報告が複数見つかりました。代表的なものは次の通りです。</p>

アップデート後に「Enable Disk(仮想ドライブのマウント)」が機能しない</li>
メニューバーのアイコンが表示されない</li>
ドライブは見えてもマウント・同期ができない</li>
ドライブ有効化時に「outdated(古い)」と表示され有効化できない</li>
</ul>
これらはフォーラムでの報告であり、「同様の事例が存在する」ことの裏付けにはなりますが、原因や解決を断定する根拠にはなりません。pCloud公式が症状ごとの原因を断定して公表しているわけでもありません。そのため、ここから先に書く原因は、あくまで私の推測として読んでください。</p>
pCloud Driveは、クラウドをローカルの仮想ドライブとして見せるために、ファイルシステム拡張(pCloudFS / macFUSE)を使います。この低レベルの拡張がロードに失敗したり、カーネル側で引っかかったりすると、アプリ単体のクラッシュにとどまらず、OS全体の挙動に波及することがあります。私が遭遇した「開こうとすると全体が不安定」という症状は、このパターンと整合します。OSのメジャーアップデート直後は、こうした低レベル拡張の互換性が崩れやすく、不安定になりがちです。</p>
pCloud Driveのアンインストール</h2>
macOS向けのpCloud DriveはApple Siliconになってから問題も多く、macOSの変更による影響も受けやすいのでうんざりしていました。</p>
OS全体を巻き込んで不安定になるアプリの回復に時間をかけるより、他の方法に移行しpCloud Driveはアンインストールすることにしました。</p>
アンインストールは次の2ステップが必要です。</p>

ログイン項目からpCloud Driveを外してmacOSを再起動</li>
pCloud Driveの削除</li>
</ol>
まずシステム設定 → 一般 → ログイン項目と機能拡張からpCloud Driveを外し、いったんmacOSを再起動して拡張の常駐を切ります。</p>
次にアプリ本体を削除です。</p>
手動で削除する場合は、pCloud Driveを完全終了(できればアプリ内でログアウト/Unlink)してから、アプリ本体をゴミ箱へ移し、~/Library</code>配下の残骸を削除します。主な残骸は次の場所です。</p>
~</span>/Library/Application Support/pCloud</span></span>
~</span>/Library/Application Support/com.pcloud.pcloud.macos</span></span>
~</span>/Library/Caches/com.pcloud.pcloud.macos</span></span>
~</span>/Library/Preferences/com.pcloud.pcloud.macos.plist</span></span></code></pre>
私が実際に使ったのは、CLIのアンインストーラであるMole(tw93/Mole</code>)です。Homebrewで導入でき、コマンド名はmo</code>になります。</p>
brew</span> install mole</span></span></code></pre>
mo uninstall</code>は、アプリ本体に加えて、launch agentやPreferences、Cachesといった関連ファイルもまとめて削除してくれます。安全のため、まず--dry-run</code>で削除対象を確認してから本実行しました。対象アプリの正確な名前は--list</code>で確認できます。</p>
mo</span> uninstall --list</span>                   # mo uninstall が受け付ける正確なアプリ名を一覧表示</span></span>
mo</span> uninstall --dry-run "pCloud Drive"</span>  # 削除対象を事前確認(変更は行わない)</span></span>
mo</span> uninstall</span>                           # 対話形式の一覧から pCloud Drive を選んで実行</span></span></code></pre>
引数なしのmo uninstall</code>は対話形式のセレクタを開くので、一覧からpCloud Driveを選んで実行します。アプリ名を引数で渡せば、対話なしで直接アンインストールできます。削除されたファイルは既定でゴミ箱へ送られるため、必要なら復元できます。</p>
Moleが消すのは、主にユーザーレベルの関連ファイルです。macOSにシステム拡張として登録された部分(pCloudFS / システム拡張)は対象外になることがあります。通常はmacOSを再起動するとクリアされますが、残っていないかは次のコマンドで確認できます。</p>
systemextensionsctl</span> list</span>   # pCloud AG の拡張が残っていないか確認</span></span></code></pre>
Mole自身も、macOS 15以降では一部の拡張系の権限エントリがアプリ削除後も残ること、そしてその種のリセットはグローバルかつリカバリモードを要するため自動では行わないことを、警告として明示しています。ツール任せにせず、最後は再起動とsystemextensionsctl list</code>での確認で締めるのが現実的です。私の環境では、ログイン項目から外して再起動したあとにアンインストールしたこともあり、最終的にpCloud AGの拡張は1つも残りませんでした。</p>
なお、pCloud Driveアプリをアンインストールしても、pCloudアカウント自体は消えません。Web(my.pcloud.com)からファイルにはアクセスできますし、消えるのは有効化済みの同期設定とカスタム設定だけです。</p>
rcloneでの設定方法とメリット</h2>
rclone</a>は、各種クラウドストレージをコマンドラインから統一的に扱えるツールです。以前「rcloneとS3ライフサイクルで作る個人データのコールドアーカイブ</a>」でAmazon S3を使った長期保管の構成をまとめましたが、pCloudもバックエンドとして公式にサポートされています。</p>
設定はrclone config</code>の対話で行います。ブラウザ認証を済ませると、設定ファイル~/.config/rclone/rclone.conf</code>が作られ、内容は次のようになります。</p>
[</span>pcloud</span>]</span></span>
type</span> =</span> pcloud</span></span>
hostname</span> =</span> eapi.pcloud.com</span></span>
token</span> =</span> {</span>"access_token":"<rclone config の認証で自動生成されるアクセストークン>"</span>,</span>"token_type":"bearer"</span>,</span>"expiry":"0001-01-01T00:00:00Z"</span>}</span></span></code></pre>
ここでtoken</code>はrclone config</code>のOAuth認証で自動生成されるものです。手で書く必要はありませんし、アクセストークンそのものなので、他人に見せたりリポジトリにコミットしたりしないよう注意してください。この記事でも実際の値はプレースホルダに置き換えています。</p>


    私はプライバシーを重視しているので、ヨーロッパリージョン(eapi.pcloud.com</code>)を使っています。</p>

</aside>

hostname</code>はリージョンを指します。eapi.pcloud.com</code>はヨーロッパリージョン、api.pcloud.com</code>(デフォルト)は米国リージョンです。アカウントがヨーロッパリージョンの場合は、ここをeapi.pcloud.com</code>に設定しておかないとトークンエラーになることがあります。通常はOAuth認証の過程で適切に設定されますが、うまくいかないときはこの値を疑ってください。</p>
設定できたら、まずは中身が見えるか確認します。</p>
rclone</span> lsd pcloud:</span>                                # トップ階層のディレクトリ一覧</span></span>
rclone</span> copy pcloud:My</span>\ </span>Pictures ~/Downloads/pics</span>  # 取り出し(ダウンロード)</span></span>
rclone</span> sync ~/work pcloud:work</span>                    # ローカルからクラウドへ同期(送信)</span></span></code></pre>
Finderのようにフォルダとしてマウントしたい場合はrclone mount</code>も使えますが、こちらはmacFUSEを必要とします。日常的なファイルの取り出しや同期は、マウントせずとも上記のコマンドだけで完結します。</p>
pCloud Driveからrcloneへ寄せる利点は、大きく2つです。</p>

macOSへの非依存</dt>
コマンドベースの転送(copy</code>、sync</code>、lsd</code>、cat</code>)はファイルシステム拡張を使わず、ユーザーランドだけで完結する。今回の不具合の原因だったpCloudFS / macFUSEとは無縁で、OSのメジャーアップデートにも振り回されない。</dd>
CLIでの自動化</dt>
CLIとなることで、launchd</code>やシェルスクリプトに組み込みが自由になる。バックアップや定期同期などを自動化して回せる。</dd>
</dl>
pCloudのサービス継続性について</h2>
ここで、pCloudというサービス自体の信頼性にも触れておきます。</p>
pCloudの大きなウリは、一度の支払いで使い続けられる買い切り(Lifetime)プラン</strong>です。
ただし、その「Lifetime」が何を指すのかは、規約を読むと印象より限定的です。pCloudの利用規約は、買い切りプランの有効期間を「アカウント所有者の生存期間か99年のいずれか短い方」と定義しています。さらに「pCloudが事業を停止した場合、アカウントは終了し、サービスは提供されない」とも明記されています。買い切りは、永久でも、企業の存続から独立した保証でもありません。</p>
そうなると運営元の規模が気になります。</p>
pCloudを提供するpCloud AGはスイスの非上場企業で社員は数十人規模、外部資本を入れないブートストラップ経営です。
非上場企業のため正確な業績は外から分かりません。出回っている年商も10億円程度1</a></sup>です。</p>
pCloudサービスは設立から10年以上続き、ユーザーも2,000万を超えて伸びており、「経営が危ない」という状況ではなさそうです。</p>
しかし、規模の小ささ自体が構造的な継続性リスクになります。買収や方針転換、大手との競争で、サービスの将来を一個人が見通すことはできません。また、規模の小ささが、今回の様な新しいmacOSへの対応の遅れの要因ともなっているかと思います。</p>
だからこそ、買い切りだからと唯一の保管先にはせず、今回のrcloneのような別経路や、ローカル・別クラウドにもコピーを持っておくのが現実的だと考えています。</p>
まとめ</h2>
macOS Tahoeとの互換性によるpCloud Drive不具合から、一旦rcloneに移行しました。</p>
とはいえ、pCloud DriveはDropboxのSmart Syncのようにキャッシュだけのローカルに置く方式で便利なので、いつか安定したら戻りたいものです。</p>
振り返ってみると、pCloudの2TBライフタイムを購入したのは2021年です。350ドル（当時のレート1ドル約109円で約38,200円）の一括払いでした。仮に、Dropbox Plusの2TBを使用していたとしたら、年額15,840円（税込）かかります。
2年半足らずで買い切りが追いつき、購入から約5年が経った今では、Dropboxなら累計8万円ほどかかっていた計算です。円で累計コストを並べると、その差がはっきりします。</p>


あまりヘビーに依存せず上手に使っていきたいと思います。</p>
References</h2>


    
pCloud</a>. 「pCloud for macOS リリースノート」</li>
pCloud</a>. 「コンピュータからpCloudをアンインストールするとどうなりますか」</li>
pCloud</a>. "Terms and Conditions"</li>
Apple Support</a>. "Delete apps on your Mac"</li>
rclone</a>. "pCloud backend documentation"</li>
Mole</a>. "tw93/Mole"</li>
</ul>

</div>




創業者の自己申告(約16.5億円)と第三者の推計(約6.6億円)で2倍以上の開きがあり、健全性を客観的に確かめる手段がありません。 ↩</a></p>
</li>
</ol>
</section>



もしかしてだけど、あれって日本最古のアスキーアートだったんじゃないの？
2026-02-21T00:00:00+00:00
はじめに</h2>

左の画像はMidjourneyで生成したものです</em></p>
1986年、パソコン通信は黎明期でASCIInetがまだ実験運用の時代でした。その頃の私はグラフィック（おそらくモノクロの有名歌手の画像）を自作プログラムでASCII文字の絵にして、あるパソコン通信のBBS（電子掲示板）に投稿しました。</p>
あれから約40年。当時のアルゴリズムをGoで再実装し、CLIツール img2char</code> として公開しました。</p>
</iframe>
この記事では、当時の背景と img2char</code> のアルゴリズムを紹介します。</p>
1986年のパソコンとBBS</h2>
1986年はPC-VAN（1986年4月実験開始）やNIFTY-Serve（1987年4月開始）が立ち上がり始めた、日本のパソコン通信黎明期です。アスキーネット（ASCII-NET）は前年の1985年5月に実験サービスを開始しており、草の根BBSも各地で産声を上げていました。通信速度は300bpsから1200bps。BBSに書き込めるのはテキストだけの時代でした。グラフィックスを書き込むなんてとんでもない時代でした1</a></sup>。</p>
当時のパソコンのグラフィック事情も触れておきます。1986年時点では、画像をファイルとして保存・交換する汎用フォーマットはまだ普及していませんでした。グラフィックを描くといえば、BASICのLINE文やPAINT文を使ってプログラムとして記述するのが主流です。私自身、PAINT文を使わずに画像の上端から下端まで（縦200ドットしかない画面です）をLINE文だけで1ラインずつ塗りつぶし、モノクロ画像を描くことに当時凝っていました。グラフィックは「描く」ものであって「ファイルで送る」ものではなかったのです。</p>
しかもBASICは機種ごとに方言が異なり、あるマシンで書いたプログラムが別のマシンでそのまま動くことはまずありません。グラフィック描画プログラムをBBSで流通させるのも現実的ではありませんでした。</p>
そこで思いついたのが、「ASCII文字絵にすれば遅いパソコン通信でも送れるんじゃね？」です。</p>
Sharp X1 ── 骨の髄までハードを極めたマシン</h2>
Sharp X1は1982年に発売された8ビットパソコンです。テレビ事業で培ったシャープの技術が随所に活かされた、ハードウェア設計の塊のようなマシンでした。</p>
当時のZ80 CPUはメモリ空間が64KBしかなく、NECのPC-8801などではこの空間にメインRAMとグラフィックVRAM（GVRAM）を重ねて配置し、バンク切り替えでアクセスしていました。一方X1は、Z80のI/O命令が実行時にアドレスバスの上位8ビット（A8〜A15）にもレジスタの値を出力するという、公式マニュアルには記載されているものの目立たない仕様を活用しました。I/O空間を実質64KBに広げ、そこにGVRAMを配置したのです。メモリ空間64KBは丸ごとRAMとして使え、GVRAMへはI/O命令で直接アクセスできます。</p>
この設計のおかげで、BASICからでもグラフィックVRAM上の画像データを読み出すことができました。グラフィックVRAM上の画像を8x8ドット単位で読み取り、キャラクタROMの各文字パターンと比較する。一致度が最も高い文字を選ぶ。このアルゴリズムをBASICで実装しました2</a></sup>。</p>
アルゴリズムの現代版 ── img2char</h2>
img2char</code> は、あの当時のアルゴリズムをGoで忠実に再現したCLIツールです。処理は3段階で構成されています。</p>

フォントパターンの準備</strong> ── 95個のASCII印字可能文字の8x8ビットマップを用意する</li>
画像のブロック分割</strong> ── 入力画像を8x8ピクセルのブロックに分割する</li>
パターンマッチング</strong> ── 各ブロックとフォントパターンのハミング距離を計算し、最も近い文字を選ぶ</li>
</ol>
フォントテーブルの構築</h3>
95個の印字可能ASCII文字（スペース 0x20</code> からチルダ 0x7E</code> まで）について、それぞれ8x8ドットのビットマップパターンを持っています。</p>
// font8x8Basic contains 8x8 bitmap patterns for 95 printable ASCII characters (0x20–0x7E).</span></span>
var</span> font8x8Basic</span> =</span> [</span>95</span>][</span>8</span>]</span>byte</span>{</span></span>
    // 0x20 ' '</span></span>
    {</span>0x</span>00</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>},</span></span>
    // 0x21 '!'</span></span>
    {</span>0x</span>18</span>,</span> 0x</span>3C</span>,</span> 0x</span>3C</span>,</span> 0x</span>18</span>,</span> 0x</span>18</span>,</span> 0x</span>00</span>,</span> 0x</span>18</span>,</span> 0x</span>00</span>},</span></span>
    // 0x22 '"'</span></span>
    {</span>0x</span>36</span>,</span> 0x</span>36</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>},</span></span>
    // ... 95文字分のパターンが続く</span></span>
    // 0x41 'A'</span></span>
    {</span>0x</span>0C</span>,</span> 0x</span>1E</span>,</span> 0x</span>33</span>,</span> 0x</span>33</span>,</span> 0x</span>3F</span>,</span> 0x</span>33</span>,</span> 0x</span>33</span>,</span> 0x</span>00</span>},</span></span>
    // 0x7E '~'</span></span>
    {</span>0x</span>6E</span>,</span> 0x</span>3B</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>,</span> 0x</span>00</span>},</span></span>
}</span></span></code></pre>
各バイトが8x8ビットマップの1行に対応し、LSB（最下位ビット）が左端のピクセルです。たとえば A</code> のパターンを展開すると、以下のようになります。</p>
(2進数はLSB=左端ピクセルから表記)</span></span>
0x0C = 00110000 → ..##....</span></span>
0x1E = 01111000 → .####...</span></span>
0x33 = 11001100 → ##..##..</span></span>
0x33 = 11001100 → ##..##..</span></span>
0x3F = 11111100 → ######..</span></span>
0x33 = 11001100 → ##..##..</span></span>
0x33 = 11001100 → ##..##..</span></span>
0x00 = 00000000 → ........</span></span></code></pre>
8バイトで1文字の形が表現されています。高速な比較のため uint64</code> にパックします。</p>
func</span> packFont</span>(</span>pattern</span> [</span>8</span>]</span>byte</span>)</span> uint64</span> {</span></span>
    var</span> v</span> uint64</span></span>
    for</span> i</span> :=</span> 0</span>;</span> i</span> <</span> 8</span>;</span> i</span>++</span> {</span></span>
        v</span> |=</span> uint64</span>(</span>pattern</span>[</span>i</span>])</span> <<</span> (</span>i</span> *</span> 8</span>)</span></span>
    }</span></span>
    return</span> v</span></span>
}</span></span></code></pre>
X1に搭載されていたHu-BASICの整数型は16ビット（2バイト）なので、当時は8バイトのパターンを2バイトずつ4回のXORループで比較していました。現代のGoでは8バイトを1つの64ビット整数に詰め込むことで、後述のXOR演算が一発で実行できます。</p>
8x8ブロックとフォントパターンの照合</h3>
ここが核心部分です。画像から切り出した8x8ブロックを、95文字すべてのフォントパターンと比較し、最も「形が近い」文字を見つけます。</p>
func</span> matchChar</span>(</span>block</span> [</span>8</span>]</span>byte</span>,</span> fontTable</span> [</span>95</span>]</span>uint64</span>)</span> byte</span> {</span></span>
    blockVal</span> :=</span> packBlock</span>(</span>block</span>)</span></span>
    bestDist</span> :=</span> 65</span> // max possible is 64</span></span>
    bestIdx</span> :=</span> 0</span></span>
    for</span> i</span> :=</span> 0</span>;</span> i</span> <</span> 95</span>;</span> i</span>++</span> {</span></span>
        dist</span> :=</span> bits</span>.</span>OnesCount64</span>(</span>blockVal</span> ^</span> fontTable</span>[</span>i</span>])</span></span>
        if</span> dist</span> <</span> bestDist</span> {</span></span>
            bestDist</span> =</span> dist</span></span>
            bestIdx</span> =</span> i</span></span>
        }</span></span>
    }</span></span>
    return byte</span>(</span>0x</span>20</span> +</span> bestIdx</span>)</span></span>
}</span></span></code></pre>
blockVal ^ fontTable[i]</code> のXOR演算で、ブロックとフォントパターンのビットが異なる位置を検出します。bits.OnesCount64</code> でその異なるビット数（ハミング距離）を数えます。64ビット中の不一致ビット数が最小の文字を選ぶ、シンプルかつ強力な方式です。</p>
使い方</h3>
入力画像は640x200または320x200ピクセルの二値化済みPNGである必要があります。前処理用のシェルスクリプトが付属しています。</p>
# 前処理（ImageMagickでリサイズ＋二値化）</span></span>
./convert.sh</span> input.jpg</span> 640 200</span></span>
</span>
# ASCII文字に変換</span></span>
img2char</span> input_640x200.png</span></span></code></pre>
640x200の画像は80x25文字、320x200なら40x25文字に変換されます。当時は320x200モードの40x25文字でやっていました。</p>
今回、同じロジックで似たような画像を変換してみましたが、なかなかいけています（冒頭の画像を参照）。</p>
もしかして......日本最古のASCII Artなんじゃないの？</h2>
当時の変換結果をパソコン通信のBBSに投稿したところ、ちょっとした話題になりました。テキストしか表示できない端末に、文字だけで画像が浮かび上がるのですから、当時としては驚きだったようです。40x25文字分の解像度しかありませんが、元の画像の輪郭や特徴が文字の組み合わせで再現される様子は、見た人を楽しませるものでした。</p>
ここで少し大胆なことを言わせてください。</p>
文字で画像を表現する試み自体は古く、1898年のタイプライターアートにまで遡ります。コンピューターによる自動変換も、1967年にベル研究所のケネス・ノウルトンがIBM 7094で実現しています。ただしそれは巨大なメインフレームでの話です。</p>
日本に目を向けると、記録に残る最古の「アスキーアート」は1986年6月20日にアスキーネット上で若林泰志が投稿した顔文字 (^_^)</code> とされています。2ちゃんねるでAAが花開くのは1999年以降。1986年当時、手作業でAA（アスキーアート）を描く文化はまだ広まっていませんでした。</p>
そんな時代に、8ビットパソコンで画像をASCII文字に変換してBBSに投稿していたわけです。</p>
もしかして、もしかしてだけど、これって日本最古のアスキーアートなんじゃないの？</strong>（どぶろっく風）</p>
......まあ、証拠は当時のBBSのログとともに電子の海に消えてしまいましたが。</p>
まとめ</h2>
img2char</code> は、1986年のSharp X1で生まれたアイデアを現代のGoで再実装したツールです。</p>

当時のパソコン通信の制約（テキストのみ）が生んだ発想</li>
PCGという強力なハードウェアをあえて使わず、ASCII文字だけで勝負した選択</li>
8x8ドットブロックとフォントパターンのハミング距離による照合という、シンプルだが効果的なアルゴリズム</li>
</ul>
40年前のBASICプログラムが64ビット整数のXOR演算に姿を変えても、やっていることは同じです。画像の形を文字の形で近似する。それだけのことが、なぜか人を惹きつけます。</p>
興味を持っていただけたら、ぜひ試してみてください。</p>
</iframe>
参考</h2>

アスキーアート - Wikipedia</a> -- 日本におけるアスキーアートの歴史、顔文字の起源</li>
ASCII art - Wikipedia (English)</a> -- タイプライターアート（1898年）からの世界的な歴史</li>
The history of ASCII Art - ASCII Art Archive</a> -- ベル研のノウルトン（1967年）による自動変換の歴史</li>
X1 (コンピュータ) - Wikipedia</a> -- Sharp X1のハードウェア仕様</li>
Z80の16ビットI/Oアドレスについての考察（大石氏）-- Z80のI/O命令が16ビットアドレスを出力する仕様の解説（サイト閉鎖）</li>
パーソナルなコンピュータのメモリ事情（第3回：8ビット中期）- Electrelic</a> -- X1とPC-8801のGVRAM配置方式の比較</li>
パソコン通信の歴史 - 木暮仁</a> -- PC-VAN、NIFTY-Serve、草の根BBSの歴史</li>
</ul>




そもそも画像をファイルに書き出すフォーマットさえ標準的なものはなかった。 ↩</a></p>
</li>

X1にはPCG（Programmable Character Generator）が搭載されており、文字のフォントパターンを自由に書き換えられました。任意のドットパターンを「文字」として表示でき、グラフィックスに近い表現が可能でした。しかしBBSに投稿するならPCGは使えません。相手の画面にPCGのデータは存在せず、表示できるのは標準のASCII文字だけだからです。 ↩</a></p>
</li>
</ol>
</section>


Evolving the MAGI System from Majority Vote to Deliberative Democracy with Agent Teams
2026-02-14T00:00:00+00:00
This is an English translation of the original
Japanese article published on Zenn:
"Agent TeamsでMAGIシステムを討議民主制に進化させた"</a></p>

Table of Contents</summary>

</details>
TL;DR</h2>

Built "Super MAGI," a decision-support plugin
that goes beyond the Evangelion-inspired MAGI
system, using Claude Code's new Agent Teams
feature</li>
Evolved from a simple majority-vote system to
a deliberative democracy where agents debate
and re-vote when opinions are split</li>
The deliberation phase dramatically improves
the quality and depth of analysis.
In practice, this reasoning process is more
valuable than the final verdict itself</li>
</ul>

</iframe>

Introduction</h2>
When Claude Code introduced its plugin system,
many developers probably had the same thought.
"Could I build the MAGI system
from Evangelion?"
The idea of multiple AI agents analyzing
problems from different perspectives
and deciding by majority vote
is a perfect use case for plugins.
Quite a few people have published
their own MAGI-inspired plugins.</p>
I was no exception.
Last year I built a MAGI plugin with
three independent AI agents,
each embodying a different persona:
scientist, mother, and woman.
Each analyzes a given problem from
its unique perspective,
and the system reaches a conclusion
by majority vote.
You can launch it simply by typing /magi</code>
in Claude Code,
optionally passing a topic as an argument
(e.g., /magi Should we adopt remote work or require office attendance?</code>).
What started as a fun experiment turned out
to be surprisingly practical.
It is particularly useful for reviewing
my own writing and code,
where it provides more diverse feedback
than asking a single AI.
It has become a tool I use daily.1</a></sup></p>
Then Claude Code announced Agent Teams.
This feature lets agents exchange messages
with each other.
I immediately thought,
"What if MAGI agents could debate
when they disagree?"
Instead of just casting votes in isolation,
they could argue their positions.
This article introduces the design philosophy
and implementation of Super MAGI,
which evolves the system from
"vote and done" to
"debate, then vote."</p>
The Original MAGI System</h2>
The original MAGI operates in three phases
as a simple majority-vote system:</p>

Phase 1 (Problem Structuring):
The ARBITRATOR works with the user
to frame the problem as a binary choice:
proposition, premises, Option A, and Option B</li>
Phase 2 (Parallel Independent Analysis):
Three agents are launched in parallel
via the Task tool.
Each analyzes and votes independently,
without seeing the others' work</li>
Phase 3 (Final Ruling):
The ARBITRATOR tallies the votes
and presents the majority decision</li>
</ul>

Phase 2 execution screen. MELCHIOR,
BALTHASAR, and CASPER running
in parallel in the background</em></p>
The three agents each have
distinct evaluation criteria:</p>
Agent</th> Perspective</th> Criteria</th></tr></thead>

MELCHIOR</td> Scientist</td> Technical feasibility, efficiency, scalability, quality of evidence</td></tr>
BALTHASAR</td> Mother</td> Legal compliance, ethical validity, risk management, impact on the vulnerable</td></tr>
CASPER</td> Woman</td> Emotional impact, UX, trend alignment, empathy</td></tr>
</tbody></table>
This system had one problem:
when the vote split 2-to-1,
the minority opinion was merely recorded.
The dissenter had no chance to rebut
the majority.
Even if the minority held
an important argument,
it might never influence the conclusion.</p>
Super MAGI with Agent Teams</h2>
In February 2026, Claude Code announced
"Agent Teams" as a research
preview.^{2</a></sup>
Previously, sub-agents could only work
independently.
With Agent Teams, agents can exchange messages
directly with each other.</p>}
When I saw this feature, I thought,
"What happens if MAGI agents debate
when they disagree?"</p>
In the original MAGI,
a 2-to-1 split simply recorded
the minority opinion.</p>
Original MAGI</strong></p>

Coded Chords - CLI

pCloud DriveのmacOS Tahoe問題

References</h2>

もしかしてだけど、あれって日本最古のアスキーアートだったんじゃないの？

フォントテーブルの構築</h3> 95個の印字可能ASCII文字（スペース 0x20</code> からチルダ 0x7E</code> まで）について、それぞれ8x8ドットのビットマップパターンを持っています。</p>

8x8ブロックとフォントパターンの照合</h3> ここが核心部分です。画像から切り出した8x8ブロックを、95文字すべてのフォントパターンと比較し、最も「形が近い」文字を見つけます。</p>

Evolving the MAGI System from Majority Vote to Deliberative Democracy with Agent Teams

TL;DR</h2> Built "Super MAGI," a decision-support plugin that goes beyond the Evangelion-inspired MAGI system, using Claude Code's new Agent Teams feature</li> Evolved from a simple majority-vote system to a deliberative democracy where agents debate and re-vote when opinions are split</li>