GitHub Issue 管理の自動化：Elisp とマレブルコンピューティングの実践

私は GitHub の Issues を利用していますが、個人的には Org Agenda で状況を追跡することを好みます。両者の整合を取るため、以前は「タイトル」と「説明」を手動でコピーして Org ファイルに転記していました。

この手作業による二重構造こそが、重複した Issue を Emacs 内のスケッチブック として活用する機会となりました。Org のノート領域だけでなく、GitHub で共有したいコメントの作成エリア（ステージングエリア）としても機能しました。しかし、この手動のコピー作業は長く続き、やがて 「これを自動化すべきだ」 という思考が避けられないようになりました。

本稿では、その自動化の実践を紹介すると同時に、Emacs のマレブル・コンピューティング能力の一側面を解説します。これは私の前掲論文「Emacs において、すべてのものはサービスのごとく見える」への追跡編です。

要件定義

自動化試みの本質的な問いは、**「何を達成したいのか」と「何を避けたいのか」**の二点にあります。

達成すべき目標（What do I want done?）

以下の機能を Org モードから実現させたいと存じます：

• GitHub Issue の追跡: Org Agenda で GitHub Issue（タイトル、説明文、メタデータなど）を容易にコピーする。
• コンテキストスイッチの最小化: Emacs での作業を主軸とし、ブラウザとの切り替えを減らす。
• 思索表現: Org シンタックスを用いて思考を表現する。
• 新規作成: 新しい GitHub Issue を作成する。
• 認証処理: GitHub の認証処理を直接扱う必要がないこと。
• ブラウザ表示: Emacs から直接、ブラウザで特定の GitHub Issue を開く。

避けるべき事項（What do I not want to do?）

以下の点に過度な労力をかけたくないと考えます：

• 本格的な GitHub CLI のインストールや記述を避ける。
• ローカル環境（Emacs）とサーバー端（GitHub）の同期論理に深く関与する。
• 多くの時間を割くこと（理想は一日以内、最長でも一週間以内で動作可能にする）。

仕様設計

次に**「どのように構築すべきか」**という問いを解決します。 今回の試みでは、既存の GitHub コマンドラインユーティリティ

gh

gh

を利用するメリット

• 認証処理の委譲: Emacs から直接認証設定をいじる必要がなく、

  gh

  に委譲できる。
• REST サービスとしての扱い: Emacs は

  gh

  を GitHub に対する REST サービスとして扱うことができる。

必要なツールとパッケージ

実装には以下の組み合わせを使用しました：

• UI: メニュー表示には

  Transient

  パッケージ、可変ピッチテーブルには

  vtable

  パッケージ。
• フォーマット変換: Org から Markdown へは

  ox-gfm

  、Markdown から Org へは Pandoc。
• データ処理:

  gh

  の JSON レスポンス解析は、Elisp 標準機能による JSON サポート。

実装

上記の実装はパッケージ

fj

fj.el

gh

(defun fj-request-issues (repo)
  "REPO の Issue リクエストを行う。"
  (let* ((fields fj-browser-fields)
         (cmd-list (list "gh"
                         "--repo"
                         (format "'%s'" repo)
                         "issue"
                         "list"
                         "--limit"
                         (number-to-string fj-request-issue-count)
                         "--json"
                         (string-join fields ","))))
    (json-parse-string (shell-command-to-string
                        (string-join cmd-list " "))
                       :null-object nil)))

コードの構造と抽象化

この関数は約 20 行で完結しており、高い抽象化度合いを実現しています：

1. リクエスト構成:

   cmd-list

   が

   gh

   実行時の引数（コマンドライン）を定義。
2. ディスパッチ:

   shell-command-to-string

   が上記リクエストを実行し結果を取得。
3. デシリアライズ:

   json-parse-string

   で JSON レスポンスを Elisp ハッシュテーブルへ変換。

取得したハッシュテーブルは vtable に埋め込まれ、以下の機能を提供します：

• 補助ウィンドウで Issue の詳細情報を表示・更新。
• Issue リストのナビゲーション。

これらにより作成された複数のコマンドは、

Transient

マレブルコンピューティングに関する考察

Elisp は動的なプログラミング言語であるため、ソースコードが利用可能であれば、リスタートなしにプロトタイプ化が可能です。これに対し、静的言語や拡張性に欠けるツールでは「編集−コンパイル−デバッグ（E-C-D）」のサイクルを繰り返す必要があります。

Emacs はコード評価のために多数の方法を提供し、ロードされた間隔離島性がないため、即興的な協調動作が可能になります：

• スクラッチバッファ
• Elisp ファイル
• Org ソースブロック
• IELM REPL
• Eshell

• eval-expression

  （

  M-:

  ）

また、Emacs から shell 経由でアクセス可能なあらゆるプログラム（

gh

pandoc

開発効率と成果

高い抽象化により必要なコード量は極めて少なく抑えられています。執筆時点での

fj.el

github.com/AlDanial/cloc v 2.08  T=0.01 s (146.4 files/s, 76550.1 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Lisp                             1             93             38            392
-------------------------------------------------------------------------------

• 目標機能の実装: GitHub から Issue をリクエストし表示する基本動作には約 2 時間半。
• 全要件の達成: 残りの時間で当初のすべての要件をカバー（以降はリファクタリングのみ）。

関心のある方は

fj.el

ソフトウェアのスコープ：比喩と逸話

90/90 の法則とパレートの法則

• 90/90 の法則: 最初の 90 パーセントのコードには、開発時間の 90 パーセントが費やされ、残りの 10 パーセントのコードにまた 90 パーセントが使われる。
• パレートの法則（80/20）: 製品の機能のうち 20％しか使われないのに、それを必要とするユーザーは全体の 80％に上る。

結論: 望む機能（BIBO 安定性＝有界入力で有界出力）が「20％のデリバラブル」に含まれる場合、結果を早く得ることができます。

サイノフスキー氏の論文への示唆

Sinofsky 氏の "What is Software Bloat, Really?" に記述されているように、Microsoft Office などの製品では機能セットに関する製品定義は製造者側に重荷があります。ユーザー調査では「Office の大部分が利用されていますが、誰も製品全体を利用しているわけではありません」と結論づけられています。

供給（Supply）vs 需要（Demand）の境界:

• 供給側ソフトウェア（例：MS Office）: 製造者が広範な観衆に応えるため、機能セットと開発スコープが広大になる。優先順位は製造者に委ねられる。
• マレブルなソフトウェア: 製造者は「建材（ビルディングブロック）」を提供し、消費者自身がツールを構築する代理権を持つ。既存のコード（Elisp など）を組み合わせて新たな挙動を生み出す。

役割の変容: マレブルなソフトウェアでは、製品定義の重荷が製造者から消費者へ移り変わります。消費者は建材から新しいツールを構築する際、自らがその責任を負うことになります。

1 人用か N 人用の構築か

「1 人用（Build for 1）」と「N 人用（Build for N）」のスコープは桁違いです。他者のためにコードを書く場合（N=2）、以下のような懸念事項を扱う必要があります：

• エラーハンドリング
• コードの保守性・モジュール化・再利用可能性
• ドキュメント、ユニットテスト、インテグレーションテスト
• パッケージング・配布

マレブルな技術の良い面であり同時に悪い面の「十分よい（just good enough）」能力は、「1 人用」の構築を促します。「私の環境で動く（it works for me）」ことが勝利宣言となることが多いためです。

多くの供給側ソフトウェアでは N 人用が必須ですが、マレブルな技術を用いる場合、N 人用かどうかは選択問題となります。

マレブルなソフトウェアとユーザーの代理権

fj

• 指定されたリポジトリの GitHub Issues を閲覧。
• GitHub Issue を Org ファイルへコピー。
• Org シンタックスを用いて新しい GitHub Issue を作成。
• ブラウザで GitHub Issue を開く。

Emacs 内に

fj

gh

pandoc

特権的な材料も要求せず、許可も不要です。マレブルな技術による個別的なエンパワーメントは、統合の少ないサイロ化されたアプリケーションを操作する作業と比較して、深い解放感をもたらします。

結びの言葉

本稿では、Emacs のマレブルコンピューティング能力について思索し、

fj.el

適切に測定された期待値（要件、機能セット、観衆）の下、マレブルな技術はもはや不可能だったツールの構築を可能にします。