List of Github [text.Baldanders.info]

Secretary as a Service

2026-05-31T03:43:36+00:00

Agents Window

最近気がついたのだが VS Code 1.120 から Agents Window なるものが追加されたそうだ。

仕事でコードを書くときは分担して作業するものなのであまり意識することはないが，独りで作業する場合，特に Go で複数のパッケージを同時に弄る場合は頭の中がとっ散らかってしまうことがある。我ながら歳をとったなぁとは思うけど。

というわけで，少しでも作業が軽減できればと Agents Window を試そうとしたんだけど，これって既存の AI エージェントとのセッションを他セッションに引き継げないのな。「どうにかならん？」と，それこそ Copilot に訊いてみたんだが，セッション履歴のインポート・エクスポート機能はあるが（つまりバックアップ・リストアはできる？），他セッションに引き継いで fork することはできないと言われた。できることは AI に引き継ぎ資料を書かせて，それを別のセッションに読み込ませるくらいだそうな。

この辺の話を Mastodon/Bluesky で愚痴ったのだが

Post by @rino@mstdn.world

View on Mastodon

みたいなポストをいただいたり。でも，ここに書かれている Claude のやり方も裏技っぽいよねぇ。他に「ZedのMCPサーバでコンテキスト共有したい」みたいな運用もあるよ，と教えてもらった。

セッションの複製や fork は必須の機能だと思うんだけど，なんで Copilot の標準機能にないの？やっぱそろそろ VS Code や Copilot は卒業すべきかねぇ。だからといって，個人利用で Claude Code とか使う気はないが。

秘書としての AI エージェント

他の記事でも言ってるけど，コーディング支援として使う AI はどちらかというとペアプログラミングしている感じ。それも新人くんとのペアプロ（笑）最初の頃は「自分で書いたほうが速い」って感じだったんだけど，反応を見ながら指示を出すことで，なんとなく AI の性格のようなものが分かってきた。 GitHub Copilot の Pro 契約で使える主なモデルはこんな感じ（個人の意見です。あしからず）。

GPT-5-mini: コストゼロで使えるのが最大のメリット。生真面目なおバカ。コード補完やコメント補完では重宝するが，エージェント・モードだと最初から明後日の方向に全力疾走する。「けもフレ」のアライさんみたいなモデル
GPT-5.3-Codex: 個人で使うエージェントとしては一番バランスが取れている。こちらの意見に追従（ついしょう）せず，ちゃんと反論できる。人間のペースに合わせてくれる盲導犬モデル
Claude Sonnet 4.6: 計画立案は上手いが，一度走り出すと融通が利かず失敗するまで突っ走るチョロQモデル。コード分析等で無闇にトークンを消費してる印象。金に糸目をつけず地球資源を濫用する富裕層向き

エージェントの使い方がちょっと変わったきっかけになったが goark/pa-api パッケージに来た PR の評価に VS Code の Copilot を使ったこと。 PA-API から Creator API に移行するための大きな変更だったので，自分だけで評価・判断するのがちょっと不安だったのだ。

実をいうと PR ページでアサインする AI レビューが使いものにならなかったのであまり期待してなかったのだが，思った以上に使えた。私は，上述の性格診断から GPT-5.3-Codex を常用しているのだが， PR に対するお互いの評価を突き合わせて「議論」が成立したことに驚いた。結城浩さんの『AIと生きる』に出てくる「AI との対話」ってこういう感じなんだなぁ，と実感したのだった。

これで我が家では Copilot はペアプロ相手の新人くんから秘書に格上げになった。 AI で秘書的な役割を演じるものとして思いつくのはグレッグ・イーガンの『万物理論』に出てくるシジフォスだな。私としてはあーゆーのが理想なんだけどねぇ。

サービスとしての秘書

個人で Go 製ツールを書くときは複数の自作パッケージを同時に扱うことが多い。そういう意味で Agents Window は便利そうなのだが，前に述べたようにセッションの複製や fork ができないのはいただけない。あと，複数のセッションを統括する AI セッションが要るよね，たぶん（セッション間の通信？）。秘書はなんぼあってもいいですからね（by ミルクボーイ）。

で，思ったんだけど，これ VS Code から分離したほうがよくね？そもそもエディタや IDE にエージェント機能を組み込むのは筋が悪いと思うのだ。だからこそ CLI インタフェースの AI エージェントが人気なんだろうけど GUI デスクトップでいまさら CUI ターミナル上で動かす意味はないよね。ブラウザ上で動かすのはもっとないけど。

というわけで Agents Window には密かに期待を寄せている。どう発展するのか分からないけど。

あと，やっぱローカル LLM は真面目に勉強しないといけないなぁ。既に AI サービスはメタクソ化が始まってると思う。早めに逃げれるようにしておかないと。

ブックマーク

VS Code 1.121 で何が変わったのか？ Agents・Mermaid・HTMLプレビュー・ターミナル最適化を整理する - Qiita

参考

万物理論 (創元SF文庫): グレッグ・イーガン (著), 山岸真 (翻訳); 東京創元社 2004-10-28; 文庫; 4488711022 (ASIN), 9784488711023 (EAN), 4488711022 (ISBN); 評価

グレッグ・イーガンの名作。これも singularity を巡る物語だな。

reviewed by Spiegel on 2017-09-18 (powered by PA-APIv5)

GitHub Copilot はシェル芸達者

2026-04-09T06:57:34+00:00

最初に予防線を張っておくと，この記事は技術系の内容ではありませんし，私は生成 AI の扱いにも慣れてません。その辺を割り引いて読んでいただけるとありがたいです。

生成 AI にどこまで任せていいのか

最近は GitHub Copilot に開発支援だけじゃなくて，このブログのメンテナンスもさせている。なにせ，どこまで任せていいのか匙加減がさっぱり分からないので，できそうなところから徐々に任せていく感じ。気分は新卒社会人の OJT だぜ（笑）

今のところ GitHub Copilot に任せているのは以下の作業：

タイトル & slug の提案と記事ファイルの作成
書いた記事の校正とタグの提案
記事ファイルの commit & push
ブログのビルドと GitHub Pages への commit & push
Hugo の更新

記事そのものは書かせてない。

いや，生成 AI に書かせるとホンマに好き勝手な（私の意図とは程遠い）ことを書くのよ。一度，タイトルだけ決めたまっさらな状態で書かせようとしたら「何の論文を書く気？」って感じのアウトラインを組み始めて，さすがに止めた。ブログ記事に10個も章立てしてどうする（笑）

よくアフィリエイト記事を AI に書かせて云々みたいな話を聞くけど，ホンマに AI に書かせてるの？かなり無茶苦茶するぞ。ある意味，文才があるのかも知れないが。

というわけで「記事を書く」以外の作業をやらせている。

ちなみにモデルは GPT-5.3-Codex を使っている。あまり Premium Request を消費したくないので最初は GPT-5 mini を使ってたのだが，どうもこの手の「作業」には向かない感じ。最終的にはローカル LLM を構築したいのだが，お試しレベルならともかく，まともに動くモデルを個人環境で構築するのは難しいか？

タイトル & slug の提案と記事ファイルの作成

私は最初にタイトルを決めないとブログ記事が書けない。マイクロブログ程度の短文ならともかく，ブログ記事でタイトルも決めずに書き始めると大抵記事が迷走する（タイトルを決めて書いても迷走しがちなのだが，それはそれ）。

手順としては

日本語のタイトルを決める（ここだけ私の作業）
Copilot に英語の翻訳と対応する slug を提案させる（たいてい複数個の候補を提案してくれる）
slug が決まったら記事ファイルを作成させる
ファイル内の front matter を埋めさせる

という感じ。日本語タイトルを英訳させるための対話で，色々と気付きがあって面白い。

たとえば日本語タイトルが曖昧で英訳が頓珍漢な文になることがある。これは生成 AI 以前の機械翻訳サービスを使ってたときもそうだったが，機械と対話することで「文のこの部分が誤解を招いてるのか」と気づいたりできるわけだ。こういったやり取りが意外と面白かったりする。

記事ファイルの作成用にシェルスクリプトを組んでいるのだが，まずその挙動を理解させるところから始めた。したら「このスクリプトをリファクタリングするか？」と訊いてきたのでやらせてみたら，なかなかいい感じに仕上げてくれた。これなら AI にスクリプトを改善させることもできそうだ。

他の既存のスクリプトについても同様にリファクタリングさせ，それらの使い方を copilot-instructions.md および README.md にまとめさせた。

書いた記事の校正とタグの提案

私のブログは意図的に文体を崩して書いているので（設計書やビジネス文書じゃあるまいし），下手に賢い lint では却って使いづらかったりする。ためしに Copilot に「誤字だけ指摘して」と指示してみたら，いい感じに結果を返してくれた。以来，校正は Copilot に任せている。

誤字だけでなく慣用句の漢字間違いの指摘とかは結構ありがたかったり。それでいて崩した文体については一切スルーしてくれる（笑）偉い偉い。

もうひとつ悩んでいるのが記事に付与するタグの選択だ。これを普通に AI に任せるとメチャクチャにしてくれるので，まずは過去の記事を全て浚ってタグの一覧を作らせるところから始めた。

したらすごい勢いでシェルスクリプトを書き始めた。私はそれを「へぇ。なるほど」とか言いながら眺めるだけ。アレだ。ペアプログラミングってやつ（笑）機械相手にペアプロすることになるとは思わなかった。

せっかくいい感じのスクリプトを書いてくれたので，それをファイルにまとめていつでも呼び出せるようにさせた。タグの一覧を出現数の多いものからソートして CSV ファイルに出力させる。ここまでできれば，作成した記事に対してタグ一覧の中から妥当なタグを提案するよう指示すればよい。

タグ一覧を作ったメリットはもうひとつあって typo がいくつか見つかったのと似たような意味のタグの重複が見つかった。見つけたのも Copilot だけど（なにせ10年以上の間にタグが450個以上できてるのだ）。これらも修正方針を提案させた上で修正させた。ファイル作業に関してはちゃんと手順を踏めば間違えることなくやってくれる。

記事ファイルの commit & push

記事ファイルの commit に関しては，念のため，最初に commit message を提案させて，私が確認してから実際の作業を行わせている。ここで GPT-5 mini と GPT-5.3-Codex の違いが大きく出た。

いや，ブログ記事の追加なんだから AI (君) のしたことを書くんじゃなくて，どんな記事を追加したのかを書けよ！

というわけで，GPT-5 mini は向いてないという結論になった。 commit & push するためのコマンドラインの組み立て自体はどちらも大差ないんだけどねぇ。

ブログのビルドと GitHub Pages への commit & push

ブログのビルドと GitHub Pages への commit & push についても以前からスクリプトファイルを作っていたので，それをそのまま Copilot に使わせている。まぁ，自分でやったほうが早いのだが，作業の一連を任せることに意味があると思ってるので，敢えて任せている。この辺も OJT っぽいよな（笑）

指示も最初はできるだけ具体的にしていたが，最近は「デプロイして」だけでも（過去の作業履歴や copilot-instructions.md の記述から）適切に処理してくれるようになった。

Hugo の更新

このブログは静的サイトジェネレータである Hugo を使って構築しているのだが，未だ v1 に到達せずベータ版のままである。古いテンプレート変数や関数のいくつかは deprecated になっているし，稀に破壊的変更が起きることもある。 Hugo のバージョンアップのたびにビルドし直して互換性等の確認をしているのだが，だんだん面倒くさくなってきたので，これも Copilot に任せてみることにした。

今回もゴリゴリとスクリプトを書き始める AI。私も前と同じく様子を眺めていたが，出来がよさそうなのでスクリプトファイルとして書き出してもらった。こんな感じ（長いぞ！）。

#!/usr/bin/env bash
set -euo pipefail

# Install latest Hugo Extended .deb from GitHub Releases using apt.
# Usage: ./hugo_inst.sh

REPO="gohugoio/hugo"
API_URL="https://api.github.com/repos/${REPO}/releases/latest"
WORK_DIR="${TMPDIR:-/tmp}/hugo-inst.$$"

cleanup() {
  rm -rf "$WORK_DIR"
}
trap cleanup EXIT

mkdir -p "$WORK_DIR"
cd "$WORK_DIR"

arch="$(dpkg --print-architecture)"
case "$arch" in
  amd64|arm64)
    ;;
  *)
    echo "Unsupported architecture: $arch" >&2
    echo "This script supports: amd64, arm64" >&2
    exit 1
    ;;
esac

echo "Current Hugo:"
if command -v hugo >/dev/null 2>&1; then
  hugo version || true
else
  echo "hugo command not found"
fi

echo "Fetching latest release metadata from ${REPO} ..."
release_json="$(curl -fsSL "$API_URL")"

version="$(awk -F '"' '/"tag_name"/ {print $4; exit}' <<<"$release_json")"
if [[ -z "$version" ]]; then
  echo "Failed to read latest release version." >&2
  exit 1
fi

asset_url="$(awk -F '"' '/"browser_download_url"/ && /hugo_extended_.*_linux-'"$arch"'\.deb/ {print $4; exit}' <<<"$release_json")"
if [[ -z "$asset_url" ]]; then
  echo "Failed to find hugo_extended .deb for architecture: $arch" >&2
  exit 1
fi

deb_file="${asset_url##*/}"

echo "Latest release: ${version}"
echo "Downloading: ${deb_file}"
curl -fL --retry 3 --retry-delay 2 -o "$deb_file" "$asset_url"

# Optional checksum verification when checksums.txt exists in latest release.
checksums_url="$(awk -F '"' '/"browser_download_url"/ && /checksums\.txt/ {print $4; exit}' <<<"$release_json")"
if [[ -n "$checksums_url" ]]; then
  echo "Downloading checksums.txt for verification ..."
  curl -fL --retry 3 --retry-delay 2 -o checksums.txt "$checksums_url"

  if awk '{print $2}' checksums.txt | grep -qx "$deb_file"; then
    echo "Verifying checksum ..."
    grep "  $deb_file$" checksums.txt | sha256sum -c -
  else
    echo "checksums.txt does not include ${deb_file}; skipping verification."
  fi
else
  echo "checksums.txt not found in latest release; skipping verification."
fi

echo "Installing ${deb_file} with apt ..."
sudo apt install -y "./$deb_file"

echo "Installed Hugo:"
hugo version

echo "Done."

これについては，私は1行も触っていない。

手順としては

インストールするマシンのアーキテクチャを確認して対応する .deb ファイルをダウンロードする
可能ならチェックサムの検証も行う
ダウンロードした .deb ファイルを apt install コマンドでインストールする

という感じ。

これを実行して Hugo を更新した後，ブログのビルドを行い，ビルド前後の差分を調べて問題がないことを確認する。問題がなければビルドしたものを commit & push させる。

「問題がないことを確認する」の部分は私が判断しているので完全な自動化ではないが，今のところ問題は起きていない。

GitHub Copilot はシェル芸達者

という感じで緩々と GitHub Copilot を使っている。

今回の一連で意外とシェル芸達者なのが分かったので，自宅機に CLI 版を入れようかなぁ。でも，結城浩さんほど使い倒す勇気はないんだよなぁ。それよりもローカル LLM 構築に向けて環境を整えるほうが先か？

参考

フルスクラッチから1日でCMSを作る_シェルスクリプト高速開発手法入門改訂2版 (アスキードワンゴ): 上田隆一 (著), 後藤大地 (著), ＵＳＰ研究所 (監修); ドワンゴ 2019-07-05 (Release 2019-07-05); Kindle版; B07TSZZPWN (ASIN); 評価

既存の常識に凝り固まったソフトウェア・エンジニアに「痛恨の一撃」を加える快書もしくは怪書。

reviewed by Spiegel on 2014-09-21 (powered by PA-APIv5)

2026年の書き初め

2026-01-04T07:09:56+00:00

みなさま，新年あけましておめでとうございます。今年もよろしくお願いいたします。今年最初のブログ記事。

昨年（2025年）のインプット／アウトプット

2024年末に「2024年のインプット／アウトプット」を書いたのを読み返して「2025年もやってること変わらんなぁ」という感想になった。以下に簡単に2025年のインプット／アウトプットをまとめておく。

ブログ

ブログに関しては，このブログ以外のアウトプットはなくなった。 Zenn や Qiita は完全に読み専になった。

SNS，マイクロブログ

インプット・アウトプット両方で使ってるのが Mastodon, Bluesky, Flickr。

Mastodon
- メインアカウント
- osanpo : よく見るサイト・ブログの監視用ボット。 Feed reader として使っている
- goark : 自作パッケージやよく利用する Go パッケージを監視して更新したらアナウンスするボット
Bluesky
- メインアカウント
- osanpo : よく見るサイト・ブログの監視用ボット。 Feed reader として使っている
- goark : 自作パッケージやよく利用する Go パッケージを監視して更新したらアナウンスするボット
- APOD unofficial : NASA APOD (Astronomy Picture of the Day) 非公式ボット
Flickr

Facebook は広島時代の友人向けの生存報告用にのみ使ってる。 Instagram, Threads はアカウントを持ってない。 𝕏 はブログ記事の宣伝と推し VTuber のチェックに使ってる。 Facebook も 𝕏 も（無料ユーザは）リンク付きのポストを冷遇するみたいな話も聞いてるし，すっかり広告媒体になっちまったなぁという感想。

GitHub

メインアカウント : 雑多な物置。主にここの管理に使っている
Playing with Go Language : 自作ツール，パッケージ管理リポジトリ

昨年の秋くらいからぼつぼつ Go で遊ぶのを再開している。入院中に PR を貰って慌てて環境を整えたり（笑）

YouTube

骨折入院で気がついたのだが，雑談配信って心とパソコン環境に余裕がないと見る気にならないのな。なので最近は歌枠やゲーム実況を主に見ている。退院して余裕ができたら未見の配信を消化していこう。

今年（2026年）はリハビリから始まる

今年に入って 1/3 荷重まで緩和され，エアロバイクも解禁された。ペダル漕ぐの楽しい。最初は様子見とケイデンス 60rpm くらいでゆっくり目に漕ぎはじめたのだが，ペースが速いとビックリされた（笑）まぁ，ママチャリだと 40〜50rpm が普通だものなぁ。好きに濃いでいいと言われたので 70rpm 付近で20分ほど漕いでいる。

今月末か来月初めくらいにはフル荷重が解禁になるので，筋力を落とさないよう楽しくリハビリしていこう。

退院したらまたフィットネスバイクと近場のサイクリングからやり直しだな。今年も心臓リハビリ＠がんばらないということで。

GitHub「変更不可リリース（Immutable Releases）」について

2025-11-11T03:59:41+00:00

気づくのが遅れたが，先日 GitHub が「変更不可リリース¹（Immutable Releases）」機能を正式リリースしたらしい。

私のリポジトリでこれを採用するかどうかは分からないが，覚え書きとして記しておく。

リポジトリに対して「変更不可リリース」を設定すると以下の機能が有効になる。

変更できないリリースを有効にすると、次の保護が適用されます。

Git タグは移動または削除できません。変更できないリリースが発行されると、関連付けられている Git タグは特定のコミットにロックされ、変更または削除することはできません。

リリースアセットを変更または削除することはできません:リリースにアタッチされているすべてのファイル (バイナリやアーカイブなど) は、変更または削除から保護されます。

さらに、変更不可リリースを作成すると、リリース構成証明が自動的に生成されます。これは、リリースタグ、コミット SHA、およびリリースアセットを含むリリースに関する、暗号で検証可能なレコードです。コンシューマーはこの構成証明を使用して、使用しているリリースと成果物が、公開された GitHub リリースと完全に一致することを確認できます。

変更不可リリース - GitHub ドキュメントより

さらに

不変リリースには、リポジトリの復活攻撃に対する保護が含まれます。リポジトリを削除し、同じ名前の新しいリポジトリを作成した場合でも、元のリポジトリの変更できないリリースに関連付けられたタグを再利用することはできません。

変更不可リリース - GitHub ドキュメントより

なんだそうだ。リポジトリを移動したらどうなるんだろう？

「変更不可リリース」を有効にする前のリリースバージョンにはこれらの機能は適用されない。逆に「変更不可リリース」有効状態でリリースしたバージョンについては「変更不可リリース」設定を解除した後も機能が残り続ける。

Once enabled:

All new releases are immutable (i.e., assets are locked and tags are protected).

Existing releases remain mutable unless you republish them.

Disabling immutability doesn’t affect releases created while it was enabled. They remain immutable.

via Immutable releases are now generally available

「変更不可リリース」はリポジトリ単位で設定できる。リポジトリの “Settings” を開き “General” 項目の “Releases” にあるチェック項目 “Enable release immutability” をチェックする。

via Repository Settings

Organization の場合は Settings で「変更不可リリース」のポリシーを設定できる。 “Code, planning, and automation” の “Repository” → “General” 項目を開き “Releases” を “All repositories” または “Selected repositories” に設定する。

via Organization Settings

“All repositories” を選択すると Organization 内の全リポジトリに「変更不可リリース」が適用される。 “Selected repositories” を選択すると適用するリポジトリを選択できる。

via Selected repositories

まぁ Go のパッケージに関しては， Go のエコシステムの中で運用する限り，リポジトリのバージョンタグは実質的に immutable なんだよな。

Go はどのようにしてサプライチェーン攻撃を低減しているか

それでも GitHub のリリースページでバイナリを配布している場合は「変更不可リリース」機能は有用なので，導入を検討してもいいかもしれない。

参考図書

初めてのGo言語第2版 ―他言語プログラマーのためのイディオマティックGo実践ガイド: Jon Bodner (著), 武舎広幸 (翻訳); オライリー・ジャパン 2025-08-05 (Release 2025-08-05); 単行本（ソフトカバー）; 4814401191 (ASIN), 9784814401192 (EAN), 4814401191 (ISBN); 評価

第2版。 Generics の説明が大幅に改訂されたらしい。練習問題も追加されている。

reviewed by Spiegel on 2025-11-02 (powered by PA-APIv5)

GitHub の公式ドキュメントで「変更不可リリース」「不変リリース」「変更できないリリース」など訳語が混在しているが，この記事では「変更不可リリース」としておく。これって生成 AI に翻訳させてるのかね。用語の統一くらいしておけよ。 ↩︎

Typst 練習用のリポジトリを作った，他

2025-03-03T11:52:58+00:00

Typst 練習用のリポジトリを作った

Typst のお勉強用に書いたコードをまとめたリポジトリを作った。

GitHub - spiegel-im-spiegel/practices-typst: Typst による組版の練習

MIT-0 ライセンスで公開しているので，再利用等ご自由にどうぞ（再利用する価値があるかどうかは別として）。

今後も思いついたことをチマチマ残していく予定。ブログのほうは「Typst に関する雑多な話」を随時更新で書き足していくつもり。これで Typst については一区切り付いたかな。

GitHub Copilot Pro に加入した

今回 Typst で遊んでたら GitHub Copilot Free 版の制限いっぱいになってしまいまして。 10秒くらい考えて Pro 版に入ることにした。とりあえず様子見で月 10USD ずつ払う。

やっぱ本格的に使うならお金を払わんとダメか。

主に VS Code でコーディング支援をしてもらってるが Typst と TypeScript で混乱してるのか，ウソの提案が多い。大抵はコンパイルエラーになるので致命的ではないが。ちゃんと統計をとってないけど体感で3割くらいしか正しくない感じ。プロ野球選手なら打率3割でエース級だが，提案が7割使えないのはちょっと困る。 Go のコードならそんなに外れはないんだけどねぇ。

Copilot に関してはローンチ当初から色々言われているが，最近でも

みたいな話があって正直いまでもビミョーな気分なんだけど，なんだかんだと便利に使っている自分がいる。生成 AI 周りはホンマ（かつての FinTech 流行時のように）山師みたいなのが多いのであまり深入りしないようにしているが，若い人が会議のテキスト起こしと議事録を作成するのに生成 AI を便利に使ってる話とか聞くと「もうそういう時代なんだなぁ」としみじみする。

まぁ，年寄りの冷水なので聞き流してください（笑）

ブックマーク

参考文献

Typst完全入門: LaTeXより簡単、Markdownより強力、美しいドキュメント作成術: doitsu (著); 2024-12-08 (Release 2024-12-08); Kindle版; B0DPXBNTRS (ASIN); 評価

マークアップ言語および組版ツールである Typst についての解説。 Kindle 版のみの提供。固定レイアウトではないためレイアウトが崩れまくって読みにくい。この手の技術解説書は固定レイアウトの Kindle 版か，いっそ PDF で出してほしい。でも Typst についてまとまった解説のある日本語の本は他に見当たらなかったのでありがたい。

reviewed by Spiegel on 2025-02-20 (powered by PA-APIv5)

GitHub Copilot で遊ぶ

2025-02-08T09:04:57+00:00

GitHub Copilot の無料版（制限あり）が開放されて VS Code 上で使えるようになった。

GitHub Copilot - Visual Studio Marketplace

といってもコメントの補完とかコミットメッセージくらいにしか使ってないけど。英語不得手なので，これだけでもめっちゃ助かっている。

ちょっと思いついて github.com/goark/koyomi/value パッケージに曜日（Weekday）型を追加しようと思うのだが，試しに GitHub Copilot に手伝ってもらうことにした。

GitHub Copilot で遊ぶ

まず Ctrl + I でプロンプトを表示し「time.Weekday と同等な機能で日本語の曜日名を出力する型」で問い合わせてみる。

time.Weekday と同等な機能で日本語の曜日名を出力する型

おー。一通り提示してくれるんだな。既に作っている koyomi/value.DateJp 型と関連するメソッドも追加されている。

これはこれで（エラーもバグもないし）使えなくもないのだが，いくつか調整したい。

WeekdayJp 型の基底型は int ではなく time.Weekday としたい
- 機能上のメリットがあるわけではないが「文芸」的に WeekdayJp 型と time.Weekday 型が「関連」することを明示したい（Go に「継承」はない）
曜日名の出力メソッドは String(), ShortString() ではなく StringJp(), ShortStringJp() としたい
- String() メソッドは time.Weekday と同じ機能にする
WeekdayJp 型の値が Sunday 〜 Saturday 以外なら，曜日名の出力は time.Weekday.String() メソッドと同じにしたい

というわけで，最終的には以下のようなコードにした。

// WeekdayJp is a type that represents the days of the week in the Japanese context.
// It is based on the time.Weekday type from the standard library.
type WeekdayJp time.Weekday

const (
    Sunday    WeekdayJp = WeekdayJp(time.Sunday) + iota // 日曜日
    Monday                                              // 月曜日
    Tuesday                                             // 火曜日
    Wednesday                                           // 水曜日
    Thursday                                            // 木曜日
    Friday                                              // 金曜日
    Saturday                                            // 土曜日
)

var weekdayNames = [7]string{"日曜日", "月曜日", "火曜日", "水曜日", "木曜日", "金曜日", "土曜日"}
var weekdayShortNames = [7]string{"日", "月", "火", "水", "木", "金", "土"}

// String returns the English name of the Japanese weekday (WeekdayJp)
// by converting it to the standard time.Weekday type and calling its String method.
func (w WeekdayJp) String() string {
    return time.Weekday(w).String()
}

// StringJp returns the Japanese name of the WeekdayJp if it is between Sunday and Saturday.
// If the WeekdayJp is out of this range, it returns the standard time.Weekday string representation.
func (w WeekdayJp) StringJp() string {
    if w < Sunday || w > Saturday {
        return time.Weekday(w).String()
    }
    return weekdayNames[w]
}

// ShortStringJp returns the short Japanese name of the WeekdayJp.
// If the WeekdayJp is not within the valid range (Sunday to Saturday),
// it returns the default string representation of the time.Weekday.
func (w WeekdayJp) ShortStringJp() string {
    if w < Sunday || w > Saturday {
        return time.Weekday(w).String()
    }
    return weekdayShortNames[w]
}

たとえば String() メソッドは

コード補完

という感じにコードを提案してくる。この状態で Tab キー押下で確定する。テストコードも関数名から推測して妥当なコードを提案してくる。変数・定数もクラス・メソッド名も名前が大事ってことですね（笑）

コメントの補完も同様。

コメント補完

ドキュメント生成もやってくれる。

ドキュメント生成

ATOM や VS Code の使い始めの頃はスニペットベースのコード補完機能に感動したものだが， Copilot によって柔軟なコード補完や生成ができるのマジ助かる。今回はコードレビュー機能等は紹介しないが，ちょろんと試した感じではなかなかいい感じである。人間にレビューを投げる前に Copilot 相手にレビューを行うのはアリかもしれない。

「自律」機械は（今のところ）存在しない

教科書に載っているサンプルコード程度ならともかく，プログラムコードに 唯一の正解 はない。今回のような小さなコードですらそうなのだ。 Copilot を含む生成 AI による提案を受け入れるか否かについては「人」による判断が不可欠だし，判断を行うためには，扱う対象に関する知識・技能・技術が要求される。「自律」的な判断を行うのは今なお，機械ではなく，人の側なのである。

自立とは、仮想代理人ソフトウェアであるところのエージェントが自ら動き、誰の力も借りずに意思決定できることを言う。 [...] 一方、自律というのは哲学的な意味であり、自らが行動する際の基準と目的を明確を持ち、自ら規範を作り出すことができることをいう。

そろそろ、人工知能の真実を話そうより

今、世の中で懸念されているのは、自立ではなく自律の方だが、学習能力を与えられ、自らのプログラムを改善できるようになっても、機械が自律することは考えられない。なぜなら、機械は結局、人間に与えられた理論やルールにのっとって行動することになるからである。

そろそろ、人工知能の真実を話そうより

GitHub Copilot をはじめとする最近流行りの生成 AI の機能とは「翻案の大量生産」であり，その膨大な翻案空間から何をどうやって拾い上げるかについては，アルゴリズムの設計を含め（今のところ）人の側に委ねられている¹。そういう意味で GitHub Copilot が文字通りコパイロット（ナビゲーション）の立ち位置に徹しているのは上手い割り切り方だと思う。

生成 AI の時代に求められる人材とはプロンプトを駆使（して翻案空間を放浪）する技能を持つ人ではなく（積極的に利用しつつ）生成 AI の提案に NO と言える見識と技術を持つ「狂狷の徒」ではないだろうか。

ブックマーク

参考図書

そろそろ、人工知能の真実を話そう (早川書房): ジャン＝ガブリエルガナシア (著), 小林重裕・他 (翻訳), 伊藤直子 (監修); 早川書房 2017-05-25 (Release 2017-05-31); Kindle版; B071FHBGW8 (ASIN); 評価

シンギュラリティは起きない。

reviewed by Spiegel on 2016-07-02 (powered by PA-APIv5)

日経サイエンス2025年3月号 [雑誌]: 日経サイエンス (編集); 日経サイエンス 2025-01-24 (Release 2025-01-24); Kindle版; B0DTT1L1KL (ASIN); 評価

Kindle 版は固定レイアウトなのでブラウザ（Kindle Cloud Reader）で読める。特集は「ことばが世界を作る」と「CO2回収の現実味」。

reviewed by Spiegel on 2025-02-03 (powered by PA-APIv5)

効率的なGo ―データ指向によるGoアプリケーションの性能最適化: Bartłomiej Płotka (著), 山口能迪 (翻訳); オライリー・ジャパン 2024-02-24; 単行本（ソフトカバー）; 4814400535 (ASIN), 9784814400539 (EAN), 4814400535 (ISBN); 評価

版元で Ebook を買える。Go言語のリファレンス本ではない。フトウェア工学，プログラミング（の考え方）を学ぶ教科書的な位置づけかなぁ。

reviewed by Spiegel on 2024-04-21 (powered by PA-APIv5)

著作権は文化を発展させるのか: 人権と文化コモンズ: 山田奨治 (著); 人文書院 2021-07-29 (Release 2021-07-29); Kindle版; B099RTG3J7 (ASIN); 評価

著作権を「ユーザーの人権」という観点から捉え直す。その後文化→コモンズ→文化コモンズと進み，本当の意味で「文化の発展に寄与する」とはどういうことか考察していく。

reviewed by Spiegel on 2022-10-23 (powered by PA-APIv5)

社会は情報化の夢を見る (河出文庫): 佐藤俊樹 (著); 河出書房新社 2010-09-03 (Release 2016-07-29); Kindle版; B01J1I8PRQ (ASIN); 評価

1996年に出版された『ノイマンの夢・近代の欲望―情報化社会を解体する』の改訂新装版。しかし内容はこれまでと変わりなく，繰り返し語られる技術決定論を前提とする安易な未来予測を「情報化」社会論だとして批判する。

reviewed by Spiegel on 2015-09-15 (powered by PA-APIv5)

作業中の BGV (メン限配信以外)

ReGLOSS の五色のバラバラな声がパズルのようにカチッと填まると本当にかっこいいよね。

生成 AI の背後にある翻案元のコンテンツやアルゴリズムと知財権との関係についてはここでは知らないふりをする。 ↩︎

2024年のインプット／アウトプット

2024-12-29T13:21:17+00:00

前回の続き。

Mastodon ではちょろんと書いたのだが，今年の私のインプットとアウトプットを整理してみる。

2024年のアウトプット

ブログ

text.Baldanders.info : ここ。本家ブログ
Zenn : 今年は1件しか書かなかった。読み専？
Qiita : 絶賛放置中。読み専

前回も書いたが，今年は技術系の記事をほとんど書いてないので Zenn の記事も1件のみ。その代わり，本家ブログでは自転車やお散歩カメラの記事が頻出している。やっぱジャンルを絞っちゃうと先細りしちゃうんだよなぁ。

SNS，マイクロブログ

Mastodon : メインの活動場所
Flickr : 写真公開場所
Bluesky : 𝕏 からの避難先
Facebook : 主に広島時代の友人への生存報告用に利用
mixi2 : 旗は立てた。どう利用していいか分からない感じ
𝕏 : 2023年から無期限休眠中。たまに生存報告
Nostr : 旗は立てたが絶賛放置中
Instagram : 2020年に足を洗った。 Threads のアカウントも持ってない

SNS やマイクロブログで書いた内容は基本的に「書き捨て」なので，サービスまたはアカウントがなくなったら消滅する。ただし写真はオリジナルを自宅 NAS にバックアップしてるので無問題。

GitHub

メインアカウント : 雑多な物置。主にここの管理に使っている
Playing with Go Language : 自作ツール，パッケージ管理リポジトリ

2024年のインプット

SNS，マイクロブログ

Mastodon
- メインアカウント
- osanpo : よく見るサイト・ブログの監視用ボット。 Feed reader として使っている
- goark : 自作パッケージやよく利用する Go パッケージを監視して更新したらアナウンスするボット
Bluesky
- メインアカウント
- osanpo : よく見るサイト・ブログの監視用ボット。 Feed reader として使っている
- goark : 自作パッケージやよく利用する Go パッケージを監視して更新したらアナウンスするボット
- APOD unofficial : NASA APOD (Astronomy Picture of the Day) 非公式ボット

メインの活動場所である Mastodon や Bluesky には Go 関連の日本語圏有名人は少ない感じ？なので Go 関連の情報が入りにくくなっている。この辺は何とかしたいが，今さら 𝕏 に戻る気はないしなぁ…

APOD 非公式ボットを始めたときは他に見当たらなかったが，最近は色んなアカウントがあって見るのが楽しい。

YouTube

言い訳しておくと，私は今でも情報収集用のメディアとして映像（動画）や音声（ラジオ）は適切ではないと思っている。「それブログで纏めてくれ」って感じである。

ただしエンターテインメントと組み合わせれば観てて楽しいし，これはこれでアリなんじゃないかと思うようになった。なので最近は今まで関心が薄かったジャンルの学術系 VTuber や自転車関連の配信をよく観る。

その他

Feedly : 絶賛放置中

Feed reader は使わなくなった。その代わり Mastodon や Bluesky のボットアカウントを使ってる。

Feedly などの feed reader はちょっと見ない間に未読が溜まりまくって収集がつかなくなるのよ。この点，タイムライン表示なら見なかったら流れ去って「なかった」ことになるので心理的安全性が高い（笑）

総評

Bluesky は企業・組織の公式アカウントが増えて情報が探しやすくなった。

それにしても，タイムライン方式は検索性が悪いと思う（できないわけではない。 Mastodon は困難だけど）。それをカバーするためにサービスプロバイダが提示する「おすすめ」順ソートがあるんだろうけど。でも「おすすめ」順ソートは「コレジャナイ」感が強いんだよなぁ。

2010年代の SNS やマイクロブログサービスはユーザを囲い込み活動を閉じ込めることに躍起になっていた。これは今でも Facebook や 𝕏 (旧 Twitter) などの老舗タイムライン・サービスで行われている。

でも本来タイムライン・サービスは「土管」に徹するべきで，そこから他サイトのコンテンツに飛ばす動線を確保するほうが理に適ってると思う。

この点で Bluesky は（今のところは）有望なんだよな。

Bluesky、1日で100万人以上増加、エンゲージメントはXの10倍以上という調査報告も | マイナビニュース

まぁ，サービス単体で収益を出そうとすると土管ではいられないんだろうけど。 Bluesky がいつその立場に立たせられるかだよね。

コミュニケーションはメッセージング・サービスか Discord のようなコミュニケーション・サービスを使うべきだと思う。はっ。もしかして mixi2 はコミュニケーション・サービスとして考えるなら有望なのでは？

ここ2,3年はニュースソースを絞ってることもあってメチャメチャ偏ってる自覚はある。ゼロ年代までで言うところのネットサーフィンにあまり時間が割けなくなっている。これは今後の課題だな。

というわけで，これでこっぽし。

OpenPGP 公開鍵の期限を延長した

2024-03-24T03:04:44+00:00

3年前に「来年からまた短期の運用に戻す」と言ったのに未だに有言不実行。今年も現行鍵の有効期限を 2025-04-01 まで延長するに留めた。

更新した公開鍵は以下の URI からインポートできる（既にインポート済みの場合は上書き更新される）。

$ gpg --fetch-keys https://baldanders.info/pubkeys/spiegel.asc

または

$ gpg --fetch-keys https://github.com/spiegel-im-spiegel.gpg

拙作の gpgpdump を使えばインポートする前に公開鍵の内容をチェックできる。

$ gpgpdump fetch https://baldanders.info/pubkeys/spiegel.asc

または

$ gpgpdump fetch https://github.com/spiegel-im-spiegel.gpg

いや Ubuntu が GnuPG 2.4 系にアップデートしてくれないので待ち状態なのよ。いきなり自前で最新版をインストールするのは怖いので，仮想環境か何かで動作確認をしないといけないのだが，これも遅々として進まず。 2024年末で 2.2 系はサポートから外れるんだけどねぇ。

最近は OpenPGP 鍵の短期運用は，期限切れの鍵が増えるだけで，あまり意味がない気がしてきた。サーバを運用しているならともかく， OpenPGP 鍵を Yubikey とかのデバイスに入れるのもあまり意味がない気がするんだよな。私は基本的にノート PC を忌避してるし。

まぁ，どのみち OpenPGP 鍵は ECC にしたいので，いつかは入れ替えなきゃいけないけどね。それもこれも GnuPG 2.4 系の環境が整ってからだ！

…というわけで，もうしばらくはグズってます。

ブックマーク

参考図書

暗号化プライバシーを救った反乱者たち: スティーブン・レビー (著), 斉藤隆央 (翻訳); 紀伊國屋書店 2002-02-16; 単行本; 4314009071 (ASIN), 9784314009072 (EAN), 4314009071 (ISBN); 評価

20世紀末，暗号技術の世界で何があったのか。知りたかったらこちらを読むべし！

reviewed by Spiegel on 2015-03-09 (powered by PA-APIv5)

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

科学2024年3月号［雑誌］: 岩波書店『科学』編集部 (編集); 岩波書店 2024-02-22 (Release 2024-03-01); Kindle版; B0CW1DZS1W (ASIN); 評価

この号の特集は「現代暗号の展開と応用」。耐量子計算機暗号や格子暗号といった今どきなキーワードも出てくる。

reviewed by Spiegel on 2024-03-01 (powered by PA-APIv5)

Mastodon と GitHub との連携

2023-02-02T00:52:56+00:00

以前にも紹介したが， Mastodon と他サイトを連携させるには， Mastodon 側のプロフィール編集の「プロフィール補足情報」で

プロフィールを編集 - Fedibird

こんな風に URL を列挙し¹，対応するサイトで

<a rel="me" href="https://hostname/@username">Mastodon</a>

とか

<link rel="me" href="https://hostname/@username">

とかいった感じのリンクを記述すればいい。のだが， GitHub のような SaaS ではサービス側が対応してくれないと難しかったりする。

GitHub の場合 github.com/username/username リポジトリを作ってその中の README.md ファイルに任意のリンクを載せられるのだが

GitHub プロファイルを（ちょっとだけ）カッコよくしてみる

外部サイトへのリンクには強制的に rel="nofollow" が上書き設定されてしまうみたいなのね。まぁ，気持ちは分かるので「しょうがないか」と諦めていたのだが， Mastodon の TL で

という投稿を見かけたので真似してみることにした。

具体的には GitHub の自ユーザページの “Edit profile” ボタンを押して編集モードにし， “Social accounts” の項目で

Edit profile - GitHub

という感じに Mastodon のプロフィール・ページの URL をセットすればよい。 mstdn.jp はアイコンがに変わるのに fedibird.com は変わらないんだな。 …まぁいいか。

この設定により GitHub の自ユーザページに

<a rel="nofollow me" class="Link--primary" href="https://fedibird.com/@spiegel">https://fedibird.com/@spiegel</a>

あるいは

<a rel="nofollow me" class="Link--primary" href="https://mstdn.jp/@spiegel">@spiegel@mstdn.jp</a>

といった感じのリンクが張られる。一方で Mastodon の自プロフィールページには

プロフィール - Fedibird

という感じに GitHub の URL にチェックマークが付く。

めでたし！

Mastodon の標準では補足情報の URL は4つまで登録できるが Fedibird は8つまで拡張されている。ところで Fedibird は 2023-02 時点でユーザが26K人を超えたらしい。そんでしばらくは新規受付を止めるらしい（招待からのサインアップは継続とのこと）。これから Mastodon は目的別にアカウント@サーバを分散させるのが賢いかもしれない。 ↩︎

AI は「創作者様」を引きずり下ろすか — 『人権と文化コモンズ』を流し読む

2022-10-23T06:06:30+00:00

ここのところ図書館で読んでたのは山田奨治さんの『著作権は文化を発展させるのか: 人権と文化コモンズ』だったり。

著作権は文化を発展させるのか: 人権と文化コモンズ: 山田奨治 (著); 人文書院 2021-07-29 (Release 2021-07-29); Kindle版; B099RTG3J7 (ASIN); 評価

reviewed by Spiegel on 2022-10-23 (powered by PA-APIv5)

またかとお思いでしょうが，またなんです。だってまとまった時間をとって読書をするのに図書館は最適の空間（affordance）なんだもの。

で，まぁ，読みながら思ったのは「これ，一回読んだだけじゃ分からんわ」だったり。なので今のところ「完全に理解した」は諦めて「最後まで読み通す」ことに注力することにした。なので今後は，何度か読み直すことになるだろう。

この記事を含めて，ブログではこの本の感想を細切れで書いていくことになると思う。理解の不備の訂正も同様。

ユーザの「表現」

『人権と文化コモンズ』で提示されている内容は私が著作権に対して抱いている問題意識と似ている，と感じている。

7年前に書き始めた「改訂3版： CC Licenses について」で私はこう書いている。

著作者や出版社にとっての著作権システムとは，著作物の「独占」状態を如何にコントロールするかであった。しかし，ユーザの場合は行動原理が異なる。それはひとことで言うなら「共有」である。何故ならユーザはコミュニケーションの手段（メディア）として著作物（＝表現）を利用するからだ。

著作権と著作権法より

一方で『人権と文化コモンズ』では表現を行使する全ての人の「人権」という観点から著作権を捉え直すところからスタートしている。つまり

人間の内面は、幾多の著作物でできている（p.64）

著作権は文化を発展させるのか: 人権と文化コモンズより

ユーザーの人権は、受け取った作品が身体化していることにその根拠がある（p.81）

著作権は文化を発展させるのか: 人権と文化コモンズより

著作者とユーザーの、両方の身体の中間に作品は立ち現れるのだ（p.89）

著作権は文化を発展させるのか: 人権と文化コモンズより

ときて

いま文化産業を名乗る彼らは、「文化」の「創り手＝送り手」を特権化して強力な保護を求め、ユーザーを消費者の位置に押し込めて、その自由を奪おうとしてきた。彼らのいう「文化」とは、その本質的な意味からは程遠い「消費財」でしかない。（p.153）

著作権は文化を発展させるのか: 人権と文化コモンズより

とまで書いている。私は不覚にも図書館内で笑いそうになった。

プログラム・コードという表現

ところで『人権と文化コモンズ』ではプログラム・コードについての言及がない（読み落としがなければ）。

現代はプログラム・コードも表現のひとつとみなされ著作権システムに組み入れられている。「著作物」という観点でプログラム・コードが小説・音楽・絵画等と違うのは「作家性」の強度だろうか。

たとえば「Linux は Linus Torvalds 作」みたいな感じで製品と作者がダイレクトに繋がっている場合もあるが，実際には一から十まで彼が全部プログラム・コードを書いているわけではなく，多数の参加者による製品に対する貢献（contribution）の上に成り立っている。この辺の話は，今や古典となった「伽藍とバザール」あたりを読むのが手っ取り早いだろう。 FOSS は「バザール型」を積極的に受け入れ，ひいては IT 産業全体の構造をも変えたわけだ。

2022年に入って AI によるコード生成支援サービスである GitHub Copilot が騒がしいが

GitHub Copilot の問題は「コードをパクっている」ことではなく FOSS を支える「自由のライセンス」まで洗い流され「ボクが考えたコード」みたいな顔をして何の前提もなく提示してしまうことにある（GitHub Copilot が知識ソースとしているのは GitHub 上の公開された FOSS コードである）。こうした「どんぶり勘定」を放っておくなら Microsoft/GitHub はいずれ困った事態に直面すると思うのだが，どうだろう¹。

AI は「創作者様」を引きずり下ろすか

もうひとつ AI 界隈で騒がしいのは「AI 絵画」だろうか。こうした話は突然出てきたように思えるかもしれないが，楽曲の世界では以前からあったし，文章を書く AI みたいな製品も存在する。

ただ「AI 絵画」を含む一連が象徴するのは「機械学習技術の民主化」であろう。

mimicのような物議然り、このフィールドはそれなりに仕組みを応用できる人がPCでも実現できる世界にすでになっているため、恐らく今後もこういうケースは続出するし、多分もう流れをせき止めることはできないと思う。良くも悪くも機械学習技術が民主化されてしまった影響。
— Hideki Saito @ メタバース技術者＆Vtuber (@hideki) August 30, 2022

例を挙げると Microsoft は GitHub Copilot と同じ技術基盤を用いて Azure 上で Dall·E 2 の提供を開始した。

［速報］マイクロソフト、Azure OpenAI Serviceで「Dall·E 2」の提供を開始、テキストから画像を生成可能。Ignite 2022 － Publickey

こうした動きは加速することはあっても巻き戻すことはもはや不可能だ。

『人権と文化コモンズ』で著者が指摘している通りに，特権者たる「創り手＝送り手」が生み出しているものが文化とは名ばかりの「その本質的な意味からは程遠い「消費財」でしかない」のであれば，この「機械学習技術の民主化」がもたらす 翻案の大量生産 は「来たるべき未来」と言うほかない。私が連想するのはスープ缶の絵を並べたあのポップアートだが，「AI 絵画」はアレの延長線上にあるように見える。

今まで「創作者様」として特権的な位置から生み出していた「創作物」が実は機械によって大量生産可能な「消費財」に過ぎなかったと， AI によって気付かされるわけだ。

人が「汗をかいて」成し遂げてきたことが機械に取って代わられるなんてことは過去に幾度も繰り返されてきたし，それによって失職する人が出たり新たな職業が生まれたりするのも歴史の必然だろう。大昔にあった「コーダー」という職業がコンピュータとソフトウェア開発環境の劇的な向上に伴って消え失せたように，将来「プログラマ」という職業もなくなるかもしれない。

情報のデジタル符号化とインターネットの台頭は，間違いなく現代におけるパラダイムシフトと言える。今ですら著作権システムはこれに適応できていないのに，さらに「機械学習技術の民主化」が進めばどうなってしまうのか。

…今回はこの辺で。

ブックマーク

参考文献

〈海賊版〉の思想‐18世紀英国の永久コピーライト闘争: 山田奨治 (著); みすず書房 2007-12-20; 単行本; 4622073455 (ASIN), 9784622073451 (EAN), 4622073455 (ISBN); 評価

「コピーライト永久独占を目論む大書店主に挑む〈海賊出版者〉ドナルドソンの肖像。法廷闘争を軸に著作権を史的に考察する。」（帯文より）

reviewed by Spiegel on 2018-11-13 (powered by PA-APIv5)

伽藍とバザール: 原題: The Cathedral and the Bazaar; レイモンドエリック, 山形浩生 (翻訳); 1999-04-16 (Release 2014-09-17); 青空文庫; 227 (図書カードNo.); 評価

プロジェクト杉田玄白正式参加作品。翻訳者のページも参照のこと。今となっては古典だけどねぇ。

reviewed by Spiegel on 2022-10-18 (powered by aozorahack)

私個人としては GitHub Copilot 問題の関心領域は少しずれたところにある。詳しくは拙文「GitHub Copilot は貢献者から貢献を奪うか？」をどうぞ。 ↩︎