■ はじめに
 |
 |
🟩ずんだもん：
今日は開発ダッシュボードのお話なのだ。Qiitaでこんな記事を見かけたのだ。
🟨つむぎ：
お〜、めっちゃ綺麗に可視化されてるじゃん！
チームでClaude Codeを使いこなしてる雰囲気がすごく伝わってくる記事✨
🟩ずんだもん：
そうなのだ。特に記事を書いている人はAIペネトレーションテストのプロダクトを扱っているとのこと。
テスト業務ではこの可視化は本当にベストプラクティスになり得ると思っているのだ。
🟨つむぎ：
じゃあ今日はその素敵な取り組みを出発点にして、「どういう業態・組織で特によく効くのか」「別のアプローチが合う場面はあるのか」 をゆるっと整理してみるって感じ？
🟩ずんだもん：
その通りなのだ。元記事の取り組みを評価するお話ではないのだ。
シナリオパターンを考える思考実験 みたいなものだと思ってほしいのだ。
🟨つむぎ：
了解〜！じゃあずんだもち食べながらゆっくり聞こっかな🍡
📌 結論を先に
- ✅ 既存プロダクトのテスト業務（特に貫通テスト） では、プロセス測定はベストプラクティスとして機能しやすい
- 🤔 一方、新規開発・リファクタリング では、プロセス測定の効果に対して運用コストが見合いにくい傾向
- 🔍 まず 自組織がテスト主体か開発主体か を見分けるのが出発点
📖 本稿の前提
- 本記事は 小規模（〜10数人程度）でアジャイルに動けるチーム を前提にしています。
- 経験則と労働論をミックスしたポエムであり、統計や検証データではありません。
■ まず最初に：自分の組織はどっち寄り？
|
|
🟩ずんだもん：
話を始める前に、ひとつ見分け方を置いておきたいのだ。
組織や部門は大きく2つの性質に分けられるのだ。
テスト主体の性質の組織／部門
- QA会社、貫通テスト会社、監査業務
- 品質の大部分が「網羅性」「手順の再現性」で決まる
- 👉 ダッシュボード／プロセス可視化は有効に機能しやすい
開発・リファクタ主体の性質の組織／部門
- プロダクト開発、内製チーム、スタートアップ
- 品質の大部分が「何が動くものとして完成したか」で決まる
- 👉 プロセス可視化は運用コストに対するリターンが小さくなりやすい
🟨つむぎ：
あー、たしかに同じ会社の中でもQA部門とプロダクト部門は雰囲気ちがうもんね〜。
🟩ずんだもん：
そうなのだ。同一会社でも、部門単位で運用を変えた方がいいのだ。
両方の性質が混ざる組織なら、プロジェクト単位で切り替えるのが現実的なのだ。
🟨つむぎ：
なるほど〜。じゃあこの話は「向き不向きがあるよね」って話なんだね✨
■ テスト業務と開発業務はそもそも別物なのだ
🟨つむぎ：
なんかかわいい絵が出てきた！ｗ
🟩ずんだもん：
元記事の人は、AIペネトレーションテストのプロダクトを扱っているようなのだ。
🟨つむぎ：
貫通テストって「網羅的に総当たりできたか」が品質に直結するやつだよね〜。
🟩ずんだもん：
そうなのだ。テスト業務は「人員リソースの稼働率」と「カバレッジ」が直接品質に効くのだ。
だからダッシュボードで可視化するのは極めて合理的なのだ。
テスト業務でダッシュボードが機能する理由
- 「やったか／やらなかったか」が二値で定義できる
- 網羅性が品質の大部分を占める
ただし、テスト業務の中にもグラデーションがある
- 貫通テストであっても、網羅性だけでなくテスト者の発想ジャンプ（想定外のアングルから試す創造性）が品質を決める局面がある。
- 「ツール利用率が高い＝質が高い」が常に成立するわけではない。
- つまりテスト業務にもプロセス測定が効く領域／効きにくい領域のグラデーションが内在する点は、忘れないでおきたい。
🟨つむぎ：
あ〜、エンジニアって発想の柔らかさが命みたいなとこあるもんね。
「決まったチェックリストだけで守れる世界」じゃないっていうか。
🟩ずんだもん：
そうなのだ。なので「テスト業務＝ダッシュボード万能」でもなく、主力は有効だが、まれに例外もある、が正しい姿勢なのだ。
■ いっぽう開発では——CI/CDの回転数が勝負
🟩ずんだもん：
開発・リファクタリング現場は、CI/CDサイクルをどれだけ速く回せるかという競技としての側面が大きいのだ。
途中のプロセスを細かく記述・測定するスタイルとは、ちょっと噛み合いづらいところがあるのだ。
開発での評価軸は「何が完成したか」の積み上げ。
プロセスを描く手間よりも、動くものを出す速度に重心を置いた方が、開発の力学とは相性が良い。
🟨つむぎ：
でもさ、「なんでその設計にしたか」は残した方がいいよね？
🟩ずんだもん：
その通りなのだ。「開発・リファクタのプロセスに至った根拠」はメモレベルで残すのがいいのだ。
1 件につき数行の断片で十分なのだ。
🟨つむぎ：
Git コミットメッセージとかADR（Architecture Decision Record）の走り書きレベルだね。
「レビュー結果」 として軽く残しておくと経営層にもちゃんと伝わるやつ〜。
🟩ずんだもん：
そうなのだ。でもツール利用率まで記録する必要はないのだ。
それは「何を考えたか」を残すのではなく「どう指を動かしたか」を残す行為なのだ。
🟨つむぎ：
指の動きカウントされたらつむぎ泣いちゃうやつ🥲
ただし「成果に近いプロセス指標」なら話は別
DORA 4キー（Deployment Frequency / Lead Time / MTTR / Change Failure Rate）のように、成果物のフロー自体を測る指標は、実証研究に裏付けられた開発向けメトリクスとして確立されている。
本稿が気にしているのは、こうした「フロー指標」ではなく、「どの道具をどれだけ使ったか」という"指の動き"の側の測定。
両者は同じ"測定"でも、測っているものが根本的に違う。
分野依存の例外もある
規制業種（金融・医療・公共など） では、監査対応のために詳細なプロセス記録が法令で要求される場合がある。
この場合は「メモレベルで十分」ではなく、規制要件を満たす記録の確保が優先される。
本稿の主張はあくまで
「一般的な開発・リファクタリング現場では、追加のプロセス可視化は過剰になりやすい」
という話であって、全領域に適用される万能ルールではない。
🟨つむぎ：
なるほど〜。法律で決まってるなら、そりゃ残さなきゃだもんね。
銀行とか病院では、しっかりしてるの大事！
■ ダッシュボード化の正体 —— 工場の稼働率管理
|
|
前提
- 本節で扱うのは「個人ごとのツール使用率を継続的に計測する」タイプのダッシュボード。
- 課金額・総利用量・導入期のadoption確認など、集計値としての可視化は別文脈として扱う。
🟩ずんだもん：
画一ツールの利用を定着させ、利用率を測定したくなる動機を一言でいうと——
「工場で機械の稼働率を測定したい」 という感覚に近い、という見立てができるのだ。
テイラー主義に近いのだ。
🟨つむぎ：
なんか教科書にありそうなやつ来た！寝ていい？
🟩ずんだもん：
脊髄反射で寝ないでほしいのだ🤢
ここで一つだけ留意点があるのだ。人間には個体差があるので、機械の稼働率と同じ文脈では扱いにくい部分があるのだ。
- 同じ人でも日によってコンディションが違う
- 得意分野が違う
- タスクの性質が違う
- 思考の"溜め"の時間は計測に乗りにくい
つまり 常に流動的なものを観察する ことになる——
この管理コストに対して、可視化で得られるリターンが見合うかどうかは、組織ごとに慎重に見たいところなのだ。
🟨つむぎ：
機械だったら稼働率100%は優等生だけど、人間が100%稼働してたら…それはもう寝てくれってなる😂
■ 歴史的コンテクスト①：パノプティコンと規律権力
🟩ずんだもん：
ここからちょっと思想史の話なのだ。眠くなったらずんだもち食べるのだ🍡
🟨つむぎ：
まかせて〜！眠くならないように煎茶も用意したから☕
パノプティコンとは
| 項目 | 内容 |
|---|---|
| 起源 | 18世紀末、Jeremy Benthamが設計した円形監獄 |
| 構造 | 中央監視塔から全独房が見えるが、囚人からは監視者が見えない |
| 核心 | 「見られているかもしれない」状態が恒常化→監視者が不在でも自己規律が作動 |
| Foucaultの発展 | 『監獄の誕生』(1975)で監獄・工場・学校・病院に共通する近代の規律権力として一般化。可視性を通じて魂を調教する権力様式 |
🟩ずんだもん：
つまり監視者がいようがいまいが関係ないのだ。
「見られている可能性」が存在するだけで行動は変質するのだ。
🟨つむぎ：
うわー…それダッシュボードにちょっと似てない？
「誰も見てないけどランキング出ちゃうから、とりあえずClaude起動しとこ」みたいなやつ〜。
補足：これはあくまで思想的なサンプル
- このパノプティコン／Foucault的解釈は、思想的フレームとしての例示にすぎません。
- 「ダッシュボード導入 → 規律権力化 → 行動変質」という因果を実証しているわけではありません。
（サンプルを適用した場合の）規律権力の問題
- 見られている感覚の内面化 ― 実際に上司が見ていなくても「使ったように見せる」行動が発生しうる
- 自己検閲 ― 「このタスクはClaudeを使うべきか」を技術的合理性でなくスコアへの寄与で判断する方向に寄りうる
- 権力の匿名化 ― 誰が何のために評価しているか不明瞭になり、異議の宛先が見えにくくなる
- 逸脱の抑制 ― 「自分でコードを書く」「じっくり考える」非計測的行為が萎縮するかもしれない
🟨つむぎ：
あくまで「かもしれない」ってことだね〜。
■ 歴史的コンテクスト②：Quantified WorkerとBossware
|
|
🟩ずんだもん：
2010年代以降、もっと直接的な流れもあったのだ。Quantified Worker と Bossware なのだ。
| 用語 | 意味 |
|---|---|
| Quantified Worker | 労働者の行動・成果をデータ化し、定量的に管理する思想。Quantified Self（自己定量化）の労務版 |
| Bossware | 従業員監視ソフトの総称（スクリーン録画、キーログ、マウス追跡、アプリ使用率計測など） |
| 代表例 | Teramind、Hubstaff、Time Doctor、Microsoft Productivity Score など |
| 背景 | テイラー主義＋デジタル監視技術の融合。COVID-19後のリモートワーク普及で急拡大 |
Quantified Worker観点で、気に留めておきたいポイント
- グッドハートの法則：「使用率」が目標化 → 不要な場面でもClaudeを呼ぶ、サブエージェント乱用で実質劣化に向かう可能性
- 測定不能労働の扱い：後輩指導・設計討議・ドキュメント読解など、スコアに現れない貢献が評価から抜け落ちやすい
- モデル選択の偏り：コスト順位を意識して、本来Opusが適切な場面でSonnet/Haikuを選んでしまう逆インセンティブ
- データの非対称性：観測される側は評価の全体像が見えづらく、観測する側だけが全体像を把握しやすい
🟨つむぎ：
グッドハートの法則なんてあるんだ。地味に怖いね〜。
「測定された瞬間、それは良い指標ではなくなる」ってやつ、経験値で分かっちゃう…。
■ 元記事の数字を、別のレンズで眺めてみる
「可視化するだけで行動が変わる」「サブエージェント利用数が約1.5倍に増加」
🟩ずんだもん：
この数字、テスト業務においては純粋に良い兆候として読めると思うのだ。一方で、開発業務に同じ仕組みを持ち込んだときにどう見えるかを、思想史のレンズでちょっとだけ眺めてみるのだ。
🟨つむぎ：
「別のレンズで見たらどう映るか」って思考実験ね〜✨
🟩ずんだもん：
Foucault的に言えば「可視化が行動を変えた」のか「可視化されることへの反応として行動が変質した」のか、数字だけからは区別しづらい——という見方もできる、というだけなのだ。
以下のような解釈の方が自然なケースも多いのだ。
- 「可視化によって、本当に価値ある活用が促進された結果として1.5倍になった」可能性
- 「元々使えていなかったメンバーが、良いきっかけを得て使い始めた」可能性
- 「ベストプラクティスの共有が進み、チーム全体のリテラシーが底上げされた」可能性
今回は「別のレンズ」側の解釈を引き出して検討してるけど、両論が併存しうることは強く意識しておきたいのだな。
🟨つむぎ：
だよね〜。同じ1.5倍でも、見方次第で景色が変わるもんね。
■ エンジニアリング実践上で気に留めておきたい傾向
開発現場で意識しておきたいポイント
- 深い思考の時間：「自分で考える時間」はスコアに現れにくい → 短絡的にAIに投げる習慣が育ちやすくなる可能性
- スキル育成の機会：基礎力を育てる機会が減り、長期的なエンジニア資産の蓄積に影響するかもしれない
- MCPの使われ方：「便利だから使う」から「スコアが上がるから使う」に動機がずれていく余地
- 心理的安全性：「使いこなせていない人」として可視化される感覚が、率直な質問・試行錯誤を控えさせる方向に働くことも
🟨つむぎ：
「使わない」って選ぶことも、ちゃんとした判断だもんね〜。
どの道具を、どの局面で、どう組み合わせるか。そのバランス感覚こそエンジニアさんの腕の見せ所な気がする！
🟩ずんだもん：
スコアを上げる最短路は「とにかく全部AIに投げる」になりがちなのだ。
でも、それだとエンジニアとしての判断力を磨く機会が減るかもしれない——くらいの温度感で読んでほしいのだ。
■ 個人経験：Plannerとバックログ二重管理の話
🟩ずんだもん：
ここからちょっと個人的な話になるのだ。
ぼくは以前こんなことがあったのだ。Plannerというアプリを使ってカンバン方式・アジャイルボード方式で開発を進め、週1回で別のバックログシステムにそれを転記して経営層に報告していたのだ。
🟨つむぎ：
おー、同じ情報を2か所で管理。転記つらそうｗ
🟩ずんだもん：
そうなのだ。しかもPlannerに簡易ワークフロー（承認システム）を組み込みたいという要望も来たのだ。
🟨つむぎ：
えっ、Plannerに承認フロー作るの？地味にめんどくさそ……。
🟩ずんだもん：
自前でメンテしつつ、かつ経営者は忙しいので承認が遅延しがちなのだ。
結果、開発や意思決定の大きなスローダウン要因になってしまったのだ……。
🟨つむぎ：
あ〜、「見える化ツール自体がボトルネック化する」やつだ〜。
ちょっぴり本末転倒かもねｗ
ここから学んだこと
プロセスを可視化するというのは「報告のコミットメント」であり「結果・成果へのコミットメント」ではない。
🟩ずんだもん：
現場が使いづらいシステムで困っているのを横目に「半年待ってください、良いものを作りますから」と承認フローを繰り返すのと——
動くものをさくっと作って可視化した状態で経営者に報告するのとでは、経営者にとっても時間効率が良いはずなのだ。
🟨つむぎ：
結局「なんかやっている風の報告」で相互に安心する気休めになっちゃうんだよね〜。
気持ちはわかるけど。
■ もう一つの観点：スコア意識が強まりすぎたときの景色
|
|
🟩ずんだもん：
ダッシュボード化して個人の"効率"が数値化されると——
スコアそのものを意識するメンバーが一定数出てくるのは、人の心理として自然なことなのだ。
🟨つむぎ：
プロセス測定はあくまで「ゴール達成のための手段」であって、プロダクトや成果物じゃないもんね〜。
スコア意識が強く出過ぎたときに起こりうる景色（極端なケース）
- ツール利用率が"良く見える"ためのちょっとしたハックが発生しやすくなる
- 目先の短期評価を追いかける空気がじわっと広がる可能性
- 真に顧客（社内プロダクトなら社内ユーザー）に向けた価値提供が後回しになる余地
- → 長期的には組織モラルに影響が出ることもあるかもしれない
🟨つむぎ：
「数字に出ないお仕事」って、地味に組織を支えてたりするんだよね〜。
後輩に教えたり、レビューしたり、ドキュメント書いたり…そういうのが見えにくくなっちゃうのはちょっと寂しいかも🥲
■ ではどうすればいいか：ハードルが下がった今、走りたい人がみんな走れる
🟩ずんだもん：
ぼくが考えるベストプラクティスはこうなのだ。
走りたい人がみんな、一斉に"よーい、ドン！"で走り出せる環境を整えるのだ。
🟨つむぎ：
運動会ｗ
🟩ずんだもん：
AIによってコーディングやデザインの負担は劇的に下がったのだ。
つまり実装のハードルが一気に下がったのだ。
これまで手を動かしにくかった人も、プロダクトを形にできるようになったのだ。
🟨つむぎ：
もちろんAI活用リテラシーとかドメイン知識は人それぞれだから、
完全に「同じスタートライン」ってわけじゃないんだけどね〜。
でも「実装できる／できない」の分厚い壁が低くなったのは事実！
「走りたい人はみんな走り出せる」世界になった、って感じかな✨
具体策：個人ごとにサンドボックスRGを割り当てる
- AWS/Azureで 開発リソースグループを個人ごとに1つ割り当て、その中では管理者権限を与える
- 「好きにやっていい」と告げる
- どんな技術スタックで開発してもOK。技術選定も個人の裁量
- 数日～1週間おきに「できあがったもの」を発表し、上位決定者にプレゼン
🟩ずんだもん：
この方式の地味に強いメリットが一つあるのだ。
各開発者が自分のRG内でオーナーシップを維持し続けられることなのだ。
これはモチベーションのキープにつながるのだ。
ただし「放任したら事故る」を避ける
個人RG案はコスト面・運用面の懸念がつきまとうので、以下のガードレールを必ずセットにする。
- コストキャップを事前に設定しておく（例：月額◯万円まで、自動的に停止）
-
RG外（他人のRG・本番環境・共有ネットワーク等）への影響は一切できない権限境界にする
- ネットワーク的にも閉じた状態にしておく
- 作れるリソース種別を事前に制限しておく（高額インスタンス、危険なリソース、公開エンドポイントなどは除外）
- 退職時のデータ回収・権限剥奪のフローもあらかじめ用意
RG内は完全に自由、RG外には一切出られない——このバランスが成立してはじめて、「自由にやっていいよ」が機能する。
🟨つむぎ：
砂場（サンドボックス）で好きに遊んでいいけど、砂場の外にはスコップ持ち出し禁止🪣って感じだね〜。
ちゃんと線引きしておけば、お互い安心して遊べる！
🟩ずんだもん：
そうなのだ。こうすれば、プロセスの測定ではなく純粋な結果の測定ができるのだ。
そして誰がどの分野に強いかが自然に共有される——
プロセス測定の上位互換として機能しうるのだ。
■ シェア方式：プレゼンなし、触れる成果物に対して匿名MVP投票
🟩ずんだもん：
運用はこうなのだ。
基本ルール
- ライブのプレゼンや発表会は採用しない
- 各自が作ったものを "触れる形"で共有スペースに置く
- 動くデモ環境のURL ／ アクセス権
- 数行の概要メモ（何を、なぜ、どう作ったか）
- 任意で短い録画・スクリーンショット
- 他のメンバーは 自分のタイミングで触って確認する（非同期）
- 匿名投票で「今回のMVP」を決める
- 定期サイクルを 継続する のが何より大事
なぜ発表会を開かないのか
- ライブプレゼンがある形式だと、プレゼンが上手い人が勝つハックが発生しやすい
- 本稿の主旨は「成果物そのもので語る」——プレゼンスキルは本質ではない
- 非同期型なら 発表疲れ・ネタ切れ・時間調整コスト の問題も避けやすい
継続のための工夫：マルチ方式でゆるく運用する
毎週ガチガチに回すと、シェア疲れが起きやすい。
続けられる設計にするため、以下をミックスして運用するのがおすすめ。
-
テーマ制の導入
- 「今週は小さな自動化」「来週はUIアイデア」など、ゆるいテーマを置く
- シェアする方向性が定まり、ネタ切れを回避できる
-
シェア形式のバリエーション
- デフォルト週：動くデモのURL＋概要メモ
- 別の週：3分以内の録画（自分のペースで撮れる）
- たまに：READMEだけでOKの気軽な週を混ぜる
-
振り返り回
- 月1や四半期に、過去のMVPをまとめて再評価する非同期ドキュメントを回す
🟨つむぎ：
プレゼン力じゃなくて、作ったもの自体で勝負するスタイルね〜。
触って確かめられるから「実際どんなもんか」がちゃんと伝わるのも健全👍
運用上のルール
- シェアされた成果物へのコメント欄での「否定」を禁止する（改善アイデアはOK）
- 感想・質問は歓迎、だが"ダメ出し"・"詰め"は禁止
- これにより強みにフォーカスした健全な競争ができる
やるべきではないこと
- 「誰より誰が良かった・悪かったか」の比較論
- 時間・量での定量的な採点
■ 組織論を超えた良い点（ポエム）
|
|
🟩ずんだもん：
ここで一つ、技術とは無関係に書いておきたいことがあるのだ。
プロセスを測定する文化には「みんなで一緒に走ろう」という無意識なやさしさという、別の側面もあるのだ。
🟨つむぎ：
あ、日本企業が1on1好きなやつだね〜。部下や後輩に寄り添うスタイル。
🟩ずんだもん：
そうなのだ。
それは効率・非効率を超えた文化としての美しさがあるのだ。
組織論より大きな視点で見ると、このプロセス測定は——
江戸時代の日本人がつちかってきた、隣人への「憐み」「情け」の発露でもあるのだ。
🟨つむぎ：
なるほど…。ただ効率だけじゃ測れない部分があるんだね〜。
「向き不向きを見極めて上手に使う」が大人のバランスかも！
そのため本稿の主張は「プロセス測定の善悪」ではありません。
「開発という営みのコアとは、噛み合わせの整合が必要」という、機能的な話です。
■ まとめ
| 分類 | トピック | 内容 |
|---|---|---|
| 🔍 判断軸 | 性質の見極め | 業務の中で「網羅性」と「発想のジャンプ」のどちらが品質を決めるかで判断。同じ会社・部門内でもタスク単位で切り替わる |
| ✅ 評価 | テスト業務 | プロセス測定はベストプラクティスとして機能しやすい（※内部にもグラデーションあり） |
| 🤔 評価 | 開発・リファクタリング | 「ツール利用率」などの画一プロセス可視化は、コストに対するリターンが見合いにくい傾向 |
| ⚠️ 懸念① | 思想史レンズ | 画一ツール利用強制＋利用率測定は、「工場で機械の稼働率を測定したい」欲望 と地続きに見える場合がある |
| ⚠️ 懸念② | Quantified Worker視点 | 規律権力の内面化（Foucault的視点）／グッドハートの法則 による逆効果 |
| ⚠️ 懸念③ | スコア意識の副作用 | ダッシュボード点数向上のためのハック、組織モラルへの影響 |
| 💡 代替案・前提 | AI時代の環境変化 | 実装ハードルが下がり、自主性・主体性をもつ開発方式 が現実的に |
| 💡 代替案① | ミニプロダクトのオーナーシップ | AWS/Azureで個人RG割り当て（コストキャップ＋権限境界＋リソース制限 のガードレール付き） |
| 💡 代替案② | 週次MVP発表 | **匿名投票＋否定禁止＋ボット検知 |
| 🌱 バランス | 寄り添い文化 | 日本企業のプロセス測定には効率を超えた美しさもあると認める |
| 🎯 スタンス | 本稿の立ち位置 | トップダウン強制プロセス と ボトムアップ合意プロセス を区別した上で、後者側に立つ |
🟨つむぎ：
つまり、開発における"見える化"は、プロセスじゃなくて成果物でやるものってことね〜。
動いているものが全部を語ってくれる。余計な説明いらない、シンプル！
🟩ずんだもん：
その通りなのだ。
「頑張ってる雰囲気になる」から、「作った」 へ。
AI時代のエンジニアは、そのシンプルさに戻ればいいのだ。
🟨つむぎ：
じゃあ今日はこのへんで—
git commit -m "こんな長いポエム最後まで読んでくれてありがとー" しとこっか〜🍡
🟩ずんだもん：そして明日から成果物として、ずんだもちそのもの を作るのだ！🍡
🟨つむぎ：物理で作る方向できたｗｗ
でも「成果物で語る」スタイル、ここに極まれりじゃん。
🟩ずんだもん：来週のMVP発表会、持参するので実食してほしいのだ！😤
🟨つむぎ：それはもう発表会じゃなくて試食会だよ😂
■ 補足
- 本稿が気にしているのは「トップダウンで強制される画一プロセス」であり、ボトムアップで合意される運用プロセスは別物として扱っています。
- 紹介したMVP発表等は あくまで一つの"案" であり、各組織の文脈に合う形にアレンジしてみてください。
利用キャラクター
- ずんだもん：VOICEVOX:ずんだもん
- つむぎ：PIXIV:りょうごさん
本記事で使用しているキャラクター画像の著作権は、それぞれの権利者に帰属します。非商用目的での利用に基づき掲載しています。