天才クールスレンダー美少女になりたい

チラシの表(なぜなら私はチラシの表にも印刷の上からメモを書くため)

【サバの話だったんだよ】WEEKLY OCHIAI vs. ゆゆ式オタク

これは東京大学きらら同好会 Advent Calendar 2021の20日目の記事です。

adventar.org

昨日(19日目)の記事はうらさんの「星屑テレパスの宇宙語フォントを作った話」でした。

n4o847.hatenablog.com








突然ですが、みなさん、ゆゆ式は好きですか?

……いえ、愚問でしたね。(ゆゆ式が好きでない人なんているはずがないので)




ゆゆ式という作品は、一言で言えば、「イベントなど特別なところの一切ない、しかしかけがえのない仲良し3人組のありのままの日常を、完全に外の視点から見せられる」作品です。
もちろん、彼女たちも普通の高校生なので大きなイベントは当然起こるのですが、作品にその描写は出てきません。「○○楽しかったね〜」みたいな感じで後から間接的に言及されるのみです。

その意味で、アニメ1期最終話のタイトル「ノーイベント グッドライフ」は、ゆゆ式の本質を突いた素晴らしい言葉だと思います。


さらに、「完全に外の視点から見せられる」というのがポイントです。すなわち、彼女たちは確かにお互いの視点を意識しているけれど、その外にいる「我々、観測者」を一切意識していないのです。
3人は観客を笑わせようとコントをしているのではなく、あくまで彼女たちが彼女たちなりに楽しんでいるのを「我々」がこっそり垣間見ているのです。それでいて私たちが見ても十分面白いのですから(つまらなかったら「ゆゆ式」という作品が成り立ちません)、なんともすごい作品だなあと思うわけです。




まあ、ゆゆ式に関する素晴らしい論考はインターネットに無数にありますし、私がわざわざ劣化コピーを作る必要もありません。

ちょうど今年も「ゆゆ式 Advent Calendar」が開催されていて、そちらにも大量に良質な記事がありますので。ぜひ。

adventar.org




さて、この作品の面白さを構成する要素として、3人の掛け合いや関係性、空気感などがあります。特に、一見しただけだと文脈が理解しづらい突飛な会話がけっこう多いです。もちろん、彼女たちは「意味不明なことを言って外野を笑わせてやろう」なんて思っていないので、あくまでも彼女たちの中では文脈がしっかり成立しているわけですが。

熟練のゆゆ式読者ともなれば、こういった突飛な会話の根底にある文脈を読むなんて朝飯前です。たぶん。










……本当に……?





ゆゆ式オタクならどんな突飛な発言でも文脈を理解できる説


というわけで、検証していきましょう。

続きを読む

DenoでScrapbox→Re:VIEW変換ツールを実装した話

これはTSG Advent Calendar 2021の17日目の記事です。前日(16日目)の記事はしとお先生の「なもり当てクイズの解き方とかコツとか?」でした。楽しみだな〜〜〜〜

adventar.org

また、東京大学きらら同好会 Advent Calendar 2021の17日目の記事でもあります。
前日(16日目)の記事は、ちさとしさんの「きららファンタジアについて、色々」でした。

adventar.org

cst-oshino.hatenablog.com


え、投稿時間が18日の0時26分? 知らんな!!!!!!!!!!





本日のお題は、私が実装したScrapbox記法→Re:VIEW記法の変換ツール「sb2re」です。

github.com



同人誌執筆とScrapboxRe:VIEW

東京大学きらら同好会では、同人誌の執筆にRe:VIEWAdobe InDesignを利用しています。前者は自由ソフトウェア、後者は不自由なプロプライエタリ・ソフトウェアです。

note.com

awomomiji.fanbox.cc



さらに、サークル内のさまざまな情報をScrapboxで管理しています。Discordだけで管理するのに向いていない、いわゆるストック情報というやつですね。



さて、前回の#FindOurStars vol.2とMicare vol.1では、一部の部員がScrapboxで記事を執筆しました。確かに、端末を変えても常に最新版を更新・閲覧できますし、進捗度合いを他の人が把握することも容易ですし、意外と理に適っている気がします。

同じような利点を持つサービスとしてGoogleドキュメントが挙げられますが、Googleドキュメントはあまりに装飾などの自由度が高く、Re:VIEWなどのテキスト形式とはさほど親和性が高くありません。docx形式でダウンロードして手作業で修正してpandoc、みたいなことになります。

一方、Scrapboxは結局テキスト形式なので、理論上は別の形式に容易に変換できることになります。これは大変便利です。

ScrapboxからMarkdown経由でRe:VIEWに変換、したはずが……

というわけで、前回の編集作業ではScrapbox形式をMarkdown形式に変換するソフトウェアを使い、そこからRe:VIEW形式のテキストを出力しました。


が、どうも利用したScrapboxMarkdown変換器の出来がイマイチだったようで、結局手で修正する羽目になりました。当時はかなりの修羅場で本当にギリギリだったので、別のツールを試す時間もなかったのです。





入稿後、いろいろ調べたのですが、「なんか結局既存の変換ツールでMarkdown経由というのはかったるいな、しかもMarkdownってシンプルな形式だから途中で書式データ失われたりしたら嫌だなあ」みたいな気持ちがあり、そのまま直接Re:VIEWにするツールを作ればいいのでは……? という気持ちになってきました。

ふぁぼん「sb2review、作りますか……」

高品質最強Scrapboxパーサ

そこで、出来のいいScrapboxのパーサが存在しないか調べてみました。そもそも本家ではテキストデータをクライアント側でパース・整形・表示しているので、だったらそのコードをライブラリとして切り出してくれていれば万々歳なんですけど。


本家のものではありませんが、めちゃくちゃ丁寧に実装・テストされているJavaScript製パーサを発見しました。

github.com


これを使わない手はありません。というわけで、実装言語はJavaScriptで決まりです。


Deno事始

ちょうどその当時の私は「Denoとかいうの、楽しそう。機会があれば使ってみたい」という気分になっていました。せっかくだし、Denoでやってみようかな〜〜、と。

そこで気になるのが、このScrapbox記法のパーサはnpmのパッケージであるという点です。そしてDenoのパッケージシステムはES Module準拠で、Node.jsのCommonJSとは互換性がありません。読み込めるんでしょうか……?


そこで、Denoからこのライブラリを利用できるか試してみることにしました。



esm.shから無事インポートできました。神。

実装実装実装実装実装実装実装実装実装実装実装実装

最高のライブラリのおかげで、無事パーサを書く必要がなくなりました。ここまでくれば、あとはやるだけです。

さまざまな記法について、パーサを通した後のASTの構造を眺め、適切なコードジェネレータを実装して適切なRe:VIEW形式のテキストを出力できるようにするだけの簡単なお仕事。


この日はかなりノリノリだったようで、本体(約210 SLOC)とテスト(130 SLOC)を勢いだけで24時間+αで実装してしまったらしいです。「それのどこがすごいの?」って言われそうですが、私はめちゃくちゃ実装が遅いんですよ。本当に。たぶん人生で一番集中してコード書いた気がします。

書くべきプログラムの構造が脳内でしっかりイメージできていたので、本当に書くだけでした。私は雑魚なので、普段はここまで明瞭にイメージできません。



ハマった点を強いて述べるとするなら、Re:VIEW形式のエスケープでしょうか。どの文字がエスケープされるべきなのかをちゃんと把握するために、手元にあったRe:VIEWプロジェクトでいろいろ試して「○○記法の中のこの文字はエスケープするべき、この文字はエスケープ不要」みたいなのを調べました。ドキュメントを参照するだけだと少々不安だったので。

CLI対応

今回は要件が単純だったので、Deno標準ライブラリ(deno_std)に含まれるflagsというオプションパーサを利用しました。Node.jsのminimistというライブラリのインスパイアらしいです。

https://deno.land/std@0.118.0/flags

標準出力に色をつけるライブラリとかも標準ライブラリに揃ってて、大変助かりました。

Denoかなり最高じゃないですか?

特に小さいプロジェクトだと、Denoは最高だと思います。いろいろごちゃごちゃインストールするまでもなくTypeScriptが使えて、しかもlinterとかテストランナーとかが揃っているので。しかも標準ライブラリが充実していて便利です。


パッケージ管理に関しては、「package.jsonがいらないから最高」というのはちょっと詭弁な気がしています。真面目にやろうと思ったら結局deps.tsとかで依存性管理しないといけないんで……npmみたいに公式でそこらへんケアしてくれてた方が楽じゃない……? 真面目にやらない書き捨てコードならともかく。
ライブラリでなければimport maps使えばいいんですけどね。


逆に言えば、書き捨てコードでTypeScriptが使えてパッケージのインストールも必要ないわけで、これは本当にありがたい話です。


あと、地味にtop-level awaitが便利です。

今後の展望

概してScrapbox記法の方がRe:VIEW記法より自由度が高いので、どうしても変換できない部分はあります。そこらへんは諦め。


あと、ユーザのことを考えると、Webで変換できるツールも欲しいですね。どうしようかなあ。


追記: 同じサークルのkn1chtさんが作ってくれました。

kn1cht.github.io







TSG Advent Calendar 2021、明日はAzaika先生の「なんかかく」です。
東京大学きらら同好会 Advent Calendar 2021、明日の記事はみゃーこ先輩先生による「アルファブロガー折部やすな ※予定はフィクションです」です。どんな記事か全く想像できなくて楽しみ〜〜〜〜


この記事は約1時間で生成されました 技術系記事じゃなければこの分量だと2時間半以上はかかってましたね

同人活動、はじめました

誰にも頼まれていないのに本を作って、そんな人が大きな会場を埋め尽くしても溢れるほど集まって、誰にも強制されていないのに本を読みたい人がたくさんやってきて。本だけじゃない、グッズも、音楽も、ゲームも。

ありとあらゆる「作ってみた」が輝くあの場所の、外から隔てられた、きらきらした「島」の中。



あそこに立ちたい。立って、自分が書いたものを読んでもらいたい——



活気あふれるインテックス大阪で。あるいは、家で寝そべりながらコミケや技術書典などの実況ツイートを見るたびに。

高校生の私は、いつしか「机の向こう側に立ちたい」と思うようになりました。


サークル名は決めた。我ながら自分にふさわしい名前になったと思う。
書きたいことはネタ帳にたくさん書き溜めた。評論も、小説も、たくさん。
だから、大学生になったら。


始めるんだ。私の人生を。
書くことは、すなわち生きることなのだから。
言葉を紡ぐことなしに生きていくなんて、私には不可能だったから。








でも。


いざ大学に入ると、そこはとても、とても大変なところで。それに、冷静に考えると本を作るには「言の葉を綴る」以外のやるべき作業が多すぎて。

いつしか私は、期日を定めた決意だったはずのそれを、「いつか、気が向いたら」にまで堕としてしまいました。



「書きたい」という欲求は、心の底でうごめいているのに。

続きを読む

TSG LIVE! 7 ライブCTF参加記

これはTSG Advent Calendar 2021の2日目の記事です。

adventar.org

前日の記事は__dAi00さんの「時の流れの速さを感じるのはいつか」でした。

qiita.com




また、この記事はCTF Advent Calendar 2021の2日目の記事でもあります。前日の記事はptr-yudaiさんの「C++のpwn/revで使うSTLコンテナの構造とバグパターン一覧」でした。

ptr-yudai.hatenablog.com

(さっきCTF AdCの存在を教えてもらい、急遽登録してみたのは秘密です)

はじめに

駒場祭(東大の学祭の1つ)の企画であるTSG LIVE! 7のライブCTFに青チームの一員として参加し、椅子を温めて終わりました。

www.youtube.com

スライドのチーム紹介で、チームAはBlueなのに赤色でチームBがRedなのに青色なのは謎でしたが。

f:id:fabonya:20211201211843p:plain
意気込み欄にマジで寒いダジャレを仕込み、当然のごとく一言も触れられずにスルーされた

TSG LIVE! とは

私の所属サークルである東大のコンピュータ系サークルTSGが、学祭などの折に実施しているプログラミング生放送です。今回で7回目になります。すごい、歴史がある
今年も去年同様に全ての企画がフルリモートでした。CTFは2日目です。


私は3日目のライブコードゴルフ大会にも企画・実況として参加しました。こっちはまあ私の実況がグダっててアレなので見てほしくない気持ちもあるのですが、それ以上に参加者から出てきたヤバいコードがすごかったので見てほしいです。たぶんCTF好きな人だったら気に入ると思います。
C言語でそんな曲芸みたいな短縮アリかよ!?」って実況中に叫びそうになりました。本当に感動した。

www.youtube.com

TSG CTF 2021のBeginner's Web 2021について

hakatashiさんが実況で「CTF初心者のふぁぼんが解けたから自信を持って出したら全然解かれなくてビギナー問詐欺と言われまくった」と言っていたのですが、ちょっと言い訳させてください。


あれはビギナーズラックです

「攻撃してみろや〜」と言わんばかりのよくわからんことをしている謎コード、しかしどういう動作をしているのか分かりづらいし、絶妙にフラグを読み出せなくて困り果て、怪しそうなasync/awaitの仕様を見ようとMDNを開いたんです。
そしたら「thenという関数を含むオブジェクトをawaitしたらPromise同等にみなされる」という記述を見て、「アッこれ使えるのでは!?」となっただけです。
オブジェクトのキー、それもメソッドをこっちで指定できると面白いことが起こせるというのは、CTFを知らない人間にもかなり自明なことだと思います。valueOfとかも使えそうですね。私はCTFに無知なので知りませんが、たぶんさんざん既出。

qiita.com

問題と解答はこれを参照してもらうとして、もうちょい詳しく解説しておきます。

{then: ()=>"hoge"}というオブジェクト(これはthenableです)をawaitすると、thenメソッドにresolveとrejectの2つの引数が渡されます。どっちもコールバック関数です。そして、resolveかrejectのどちらかを呼ぶまでawaitは返ってきません。しかしthenメソッドは単に"hoge"という文字列を返すだけのメソッドになっているので、awaitは永遠に返ってこない。こうして処理を途中で止めることに成功したわけです。


……私は本当にCTFを知らなくて、開発者として単にJavaScriptを多少知ってたのと、あとは運でした。はい。

参加記 環境編

全部自分で設定・構築したLinuxデスクトップを使い、エロゲソングプレイリストを流しながら参加しました。ウィンドウマネージャはXMonadです。dotfilesはこちら。ちなみにデュアルディスプレイです。XMonadデュアルディスプレイに問題なく対応してて神。

github.com

f:id:fabonya:20211201220347p:plain
放送のアーカイブからキャプチャ。再生しているエロゲソングのタイトルが左上に表示されている。このキャプチャは「恋がさくころ桜どき」の挿入歌「Distance」。

www.youtube.com

参加記 本番編

問題はこちらを参照してもらえれば。

github.com



これはネタバレですが、椅子を温めて終わりました。




私は暗号も代数もリバースエンジニアリングも一般的な脆弱性も分からないので、問題の意味を理解できるものがWebしかありませんでした。そしてWebは1問だけ。選択肢がない状況というのは、迷いが生まれる余地がなく思考停止できるという点で割と楽だったりします。


さて、CTFにおいてsanity checkというのは簡単な「ちゃんと接続できたかな〜」みたいな感じの問題のことなのですが(以前ちょっとCTFについてググったときに知りました)、「いや唯一のWeb問がsanity checkってどういうこと?」と思いつつアクセスしてみると「SAN値チェックツール ダイスを振れます」って出てきて、「クトゥルフかぁ〜〜〜〜」となりました。クトゥルフTRPGもなんも知らんけど……


とりあえず、動作を確認してみます。どうやら/dev/urandom/dev/randomを元に乱数を生成しているようです。(ちなみに、試している最中にrandomのリクエストが返ってこなくなってました。後で知ったのですが、どうやらエントロピー切れによりrandomが読み出せなくなっていたようです)

次に、サーバ側のソースが見れたので、そっちを見てみようと思います。

const stream = fs.createReadStream(`/dev/${source}`, {end: count * 4});

おー、ディレクトリトラバーサルやないかい。その特徴はもう完全にディレクトリトラバーサルやがな。sourceに"../etc/passwd"とか設定したら/etc/passwd読めるやないか。

const stream = fs.createReadStream(`/dev/${source}`, {end: count * 4});
const data = await get(stream, {encoding: 'buffer'});
return Array(count).fill().map((_, i) => (
	data.readUInt32BE(i * 4) % n + 1
));


唐突なミルクボーイはさておき(どうでもいいけど私はお笑い芸人だと金属バットが好きです)、しかし単純に読めるというわけではなさそう。読んだデータを数値の配列に変換してnで剰余取ってる感じですね。(というだけの読解に5分か10分くらいかけた。コードリーディングが亀のように遅太郎と申します……)

さて、フラグを得る方法は……

const flag = process.env.FLAG;

なるほど、環境変数ですか。

app.post('/', async (req) => {
	const {source, message} = req.body;
	if (message.length >= 7) {
		return 'Too long!';
	}
	const [count, n] = message.split('d').map(Number);
	const numbers = await getRandoms(n, count, source);
	const sum = numbers.reduce((a, b) => a + b);
	if (sum === 77777) {
		return `Jackpot!!! ${flag}`;
	}
	return numbers.join(' + ') + ' = ' + sum;
});

お、乱数の合計が77777になるとflagが開示されるようです。さっき乱数の元ファイルを自由に指定できるのが明らかになったので、いい感じになるような元ファイルとダイスロール指定を組み合わせれば解けるでしょう。

とりあえず、冒頭4文字が判明してる/etc/passwdを指定して、uint32として読み込んだ値を調べて、その値のmodを取ったときに77776になるような法を素因数分解使いつつ調べて……よしできた、942941だ。さあ実行するぞ!



……と思っていた時期が私にもありました。

// messageは2d6などのこと
if (message.length >= 7) {
	return 'Too long!';
}

はい、modの法もロール回数も、合計で5文字以下と指定されています。さっき求めた法は6桁です。悪いことはできないもんですね。

なお、これは終わった後の感想戦でTSG外のCTFerに言われたことなのですが、77777d1とか指定できちゃうと確定で77777にできます。確かに。コロンブスの卵だ……


振り出しに戻る。




冷静に考えると、たとえファイルを指定できたとしても、99d999の最大値が98901なのに対して77777を狙うのは厳しい気がします。/dev/zeroは永遠に0(ダイスだと1)ばかり吐き出すし、逆に1を延々と吐き出すデバイスファイルは存在しないですし……
大量のファイルを総当たりすれば1つくらいは当たるかもしれませんが、そもそも私はサーバにあるファイルのリストを持っていませんし、手の出しようがありません。何より、hakatashi先生ならそんなエスパー+DOS一歩手前の方法を想定解にしない、という信頼がありました。

まあ、今回に関しては単にDOSはよろしくないという話ですけどね。一般的な話として、想定解でなかろうがフラグ取ってナンボのCTFにおいて力技を試しもせずに諦めてしまうのは、私のCTFプレイヤーとしての重大な弱点とも言えそうです。実装の遅さとそれに起因・関連する諦めの早さはCTFに限らないですが……




このあたりで少し焦り始めます。

ふぁぼん「このままだとマジで椅子温めただけで終わるカスになってしまう ヤバい」
青チーム内チャンネルで焦りを吐露するふぁぼん選手

というわけで、文字列チェックをすり抜ける方法を考えてみます。

まず、bodyに任意JSONデータを入れられるので、{message:{length: 5}}みたいにしてみるとどうなるでしょう?
結論から言うと、どう足掻いてもsplitメソッドを呼べず死にます。JSONでメソッドは作れないですからね。というか作れたらセキュリティがヤバいだろ。

次に、16進数表記などを使って範囲を拡張できないか試してみたのですが、16進数なら先頭に0xをつける必要があり、よけい指定できる範囲が狭くなりました。ダメだこりゃ。








万事休す。






光陰矢のごとし。

打てる手はなく、app.jsを眺めては攻撃の糸口が見つからないとため息をつくだけの時間。チームメイトのQueryさんとmikanamiさんがどんどん問題を解いてチームの得点に貢献しているのをただ傍観するだけ。


しかし、終了15分前くらいで、ようやく重要な気付きを得ました。






これ、複数の元で試せば中国剰余定理によって元の値、そしてファイルを復元できるのでは? つまりサーバの任意ファイルを読み出せるんじゃ?

たとえば99dxxxとすれば冒頭396バイトを読み出せる計算です。これだと3桁のmodしか取れないですが、4つの法を試せば最大公約数が2^{32}を超え、元の値を一意に定めることができます。32ビット符号なし整数は最大が2^{32}-1なので。

中国剰余定理は極めて有名な典型問題なので、ソルバくらいどっかに落ちてるでしょ。









で、何のファイルを読めというんですか? なんかflag.txtというファイルがソースに混ざっていたのですが、こいつを読めばいいんでしょうか? でも本番環境でこのアプリのソースがどこに配置してるかなんて私には分かりませんし……

ちなみに、後から分かったことですが、このファイルはミスで混入してしまっただけで、本番環境のflag.txtにも正しいフラグは書かれていなかったらしいですね。

f:id:fabonya:20211201234854p:plain
手を差し伸べてくれる優しいQuery先生




タイムアップ。
0完太陽。
椅子を温めただけ。



反省

後でCTFの放送部分を見たのですが、実況の人(特にJP3BGYさん)が中国剰余定理パートについて「(Cryptoが得意で数学に詳しい)Queryくんに計算してもらって! 情報共有して!」と叫んでて面白かったです。

今回に関しては、まあ復元しようにも復元すべきファイルが分からなかったので、相談したところで変わらなかったわけですが。しかし、諦めが早すぎる上に1人で抱え込みがちなのはかなり根深い問題で、克服すべき1つの壁なのだと思います。
道筋が見えて自分でもやればできると確信してしまうと(実際時間があれば可能なわけですが)、間に合うか怪しく自分より詳しい人がいるというような状況ですら、相談するという選択肢が見えなくなっちゃうんですよね……

解き直し

放送中、最後のインタビューでちらっと触れられてたのですが、プロセス自身の環境変数(ただし初期のものだけ、内部で再設定したものは別)が格納されてる/proc/self/environというデバイスファイルを読み出せばよかったらしいです。(余談ですが、/procはたぶんBSDには存在しないGNU/Linux限定のディレクトリだと思います)

どうやら本当にあと一歩わずかに及ばずというところだったらしく、しかし知らないものは知らないので、悔しいけどどうしようもなかったかな……と思っています。/procにもデバイスファイルがあるということを完全に失念していました……そもそもの話として環境変数を読みにいくという発想もなかったのでオワリです。


linuxtut.com

中国剰余定理のソルバはこのサイトのものをお借り(コピペ)して、実際に977と983と991と997を法として試してみました。/proc/self/environ環境変数をnull文字区切りで出力するようなのですが、まあそんなのはコード見れば分かるか。62d977とか62d997とか送りつければいい、というわけです。

# ↑上のサイトからcrtメソッドをコピペしてくる。ただし1箇所typoがあったので、そこだけは直す。
# ↓ここから私のコード

r983 = "816 + 913 + 485 + 924 + 849 + 840 + 545 + 366 + 816 + 968 + 855 + 761 + 674 + 610 + 551 + 212 + 50 + 296 + 7 + 288 + 803 + 507 + 351 + 271 + 670 + 377 + 351 + 271 + 653 + 693 + 953 + 578 + 978 + 256 + 892 + 377 + 30 + 273 + 852 + 743 + 956 + 362 + 354 + 410 + 750 + 549 + 81 + 705 + 107 + 236 + 401 + 873 + 404 + 330 + 564 + 369 + 770 + 251 + 390 + 864 + 64 + 552".split(" + ")
r991 = "411 + 498 + 386 + 933 + 151 + 929 + 10 + 586 + 401 + 870 + 904 + 841 + 388 + 78 + 527 + 895 + 487 + 168 + 244 + 242 + 919 + 522 + 532 + 305 + 895 + 306 + 532 + 305 + 878 + 591 + 699 + 49 + 274 + 955 + 905 + 306 + 453 + 38 + 846 + 368 + 3 + 344 + 971 + 188 + 447 + 987 + 296 + 437 + 898 + 800 + 943 + 624 + 182 + 776 + 924 + 278 + 21 + 657 + 431 + 217 + 648 + 827".split(" + ")
r997 = "980 + 269 + 910 + 483 + 508 + 159 + 680 + 224 + 757 + 925 + 626 + 686 + 850 + 47 + 870 + 693 + 416 + 694 + 99 + 488 + 730 + 578 + 285 + 643 + 182 + 799 + 285 + 643 + 165 + 995 + 431 + 321 + 166 + 426 + 609 + 799 + 781 + 64 + 125 + 349 + 246 + 669 + 376 + 648 + 343 + 571 + 924 + 679 + 326 + 542 + 258 + 210 + 642 + 687 + 766 + 901 + 459 + 150 + 714 + 415 + 601 + 362".split(" + ")
r977 = "828 + 652 + 143 + 780 + 732 + 450 + 46 + 717 + 737 + 786 + 623 + 432 + 147 + 566 + 396 + 829 + 283 + 283 + 146 + 419 + 749 + 970 + 729 + 951 + 22 + 402 + 729 + 951 + 5 + 392 + 568 + 582 + 675 + 548 + 362 + 402 + 610 + 168 + 953 + 135 + 107 + 193 + 870 + 305 + 826 + 712 + 56 + 461 + 915 + 598 + 119 + 188 + 299 + 628 + 952 + 894 + 787 + 768 + 174 + 638 + 184 + 161".split(" + ")
a = r983.zip(r991,r997,r977).map do |e|
    crt(e.map{_1.to_i-1},[983,991,997,977])[0]
end
puts a.pack("N*").split("\x00")
NODE_VERSION=16.13.0
HOSTNAME=ba00ae60e06f
YARN_VERSION=1.22.15
SHLVL=2
HOME=/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/app
FLAG=TSGLIVE{Ph'nglui_mglw'nafh_Cthulhu_R'lyeh_wgah'nagl_fhtagn:_SANITY_CHECK_FAILED!!!!}

クトゥルフですね。もれなくSAN値チェック失敗してますが……


CTFの楽しさ 〜ミステリオタクかつCTF超初心者の視点から〜

良いCTFの問題を解くのには本格ミステリの「読者への挑戦」を考えるのと似た楽しさがあるんじゃないか——
たった数問しか解いてない人間がこんな適当なことを言うのはアレですが、なんとなくそう思っています。ちなみに私はミステリ、特に本格推理の大ファンです。

「お前はCTFのことを何も分かってない、単なるその作問者の作風を共通の性質だと思い込む低能がよ……」とか言われるのがマジで怖いので全力で予防線を張っておきますが、「フラグを読み出す」という一見不可能な問題を与えられるCTFには明らかに不可能状況のハウダニットの要素があると思います。さらに、エスパーせずに解けるようになっている問題なら、それはすなわち「読者への挑戦」と同じようなものではないでしょうか。

もっとも、ここまで強く「本格ミステリっぽくて楽しい」と思えたのは初めにhakatashi先生の問題に触れられたからで、そういう意味で私はとても幸運だったのでしょう。
(中2の正月にksnctfに手をつけて、Crawling Chaosは解いたもののCTFが何か全くわからずやめてしまった過去があります)

「この変数をセットした上でこの関数を実行すればフラグが出力されるが、実行するとそもそも変数が書き変わってしまう。どうする?」と「このナイフで刺せば殺人現場を再現できるが、そのナイフが置かれた部屋は密室で、鍵の番号を知っている人には全員アリバイがあった。犯人はどうやって被害者を殺した?」ってそんな変わらないと思うんですよ。
あと、ミステリの定石「自明だと思い込んでいる前提を疑う」はCTF解くときでもけっこう強い気がします。






まあ、ミステリ・CTF比較論はそのうち私がCTFに慣れて「web問ってだいたいこんな感じだなあ」というのが分かった頃にちゃんと論じることにします。結局「hakatashi先生の問題が特殊なだけで、一般的にはいうてそんなミステリっぽくないな……」って結論になっちゃうかもしれませんが。

蛇足 読者プレゼント(カスのweb問)

TSG CTFの数日後にCTF知識ゼロのオタクが作ったマジのゴミカスweb問を進呈します。「それなりに考えて作ったけど、どうせ典型なんやろうなあ。どんな典型テクニックがあるかすら知らんけど……」と思って雑に投げたら実際典型だったようで、秒で解かれてウケてました。あまりに典型すぎたのか「無から典型を錬成できるの、才能ありそう」などとフォローが飛んでくる始末。

ちなみに、さっきも触れた話ですが、こういうの考えるのってミステリのトリックを考えるのと同じような楽しさがあるし、なんならミステリのトリックを考えるときの思考法をまんま流用できちゃうんですよね。核心となるトリックを考える、謎の焦点をズラす、ミスリードを狙う、など。

なので、仮に私に才能があったとしても、それはたぶんCTFじゃなくてミステリ書きの才能なんじゃないでしょうか。知らんけど。(ネタ帳に溜まってるカスのミステリのネタから目を逸らしつつ)

// サーバのソース app.js
const fastify = require('fastify')({ logger: true });
fastify.register(require('fastify-formbody'));

const routes = {
  flag: ()=>'FLAG{hogefugapiyo}',
  count: data=>data.length
};

fastify.post('/', (request, reply)=>{
  const action = request.body.action;
  if (action.includes('f')) {
    return { message: "Don't use the F-word!!!" };
  }
  const res = routes[action](request.body.data);
  return { result: res };
});

const start = async () => {
  try {
    await fastify.listen(3000);
  } catch (err) {
    fastify.log.error(err);
    process.exit(1);
  }
}
start();



CTF Advent Calendar、次回は7日のFurutsukiさんです。

TSG Advent Calendar、明日……は今のところ空き枠で誰も埋めてないのですが、次の記事は5日のhideo54さんによる「なんかかく」です。お楽しみに!

サークル「東京大学きらら同好会」の合同誌2冊に文章を3本寄稿して即売会で売ってきた話

サークル(ダブルミーニング)









サークル「東京大学きらら同好会」で10月24日開催の即売会「よんこま文化祭」に参加し、恋する小惑星合同誌「#FindOurStars vol.2」と、「きらら」合同誌の「Micare vol.1」(+一瞬で完売した既刊「#FindOurStars vol.1」若干冊)を頒布しました。




www.melonbooks.co.jp

www.melonbooks.co.jp

メロンブックスで委託販売してもらっています。よってメロブの通販で買えます。あるいは、店舗取り寄せ(さくっと注文)を利用すると送料とか手数料が割と安くなります。もともとたかが100円ですが、取り寄せ商品の合計額が1100円を超えると手数料無料になるんですよ。

特にMicareの方が在庫僅少です。欲しい方はお早めに。まあどうせそのうち増刷しますけど、しばらく先になりそうなので。

本の紹介

#FindOurStars vol.2

恋する小惑星の合同誌、なんと2巻です。

utkiraracircle.github.io

ナナチカ探偵団と不可能な虹」は、ミステリオタクの私が割と真面目に書いた地理地学百合ライトミステリです。ミステリのオタクにも読んでほしいけど、ミステリのオタクに読まれるのは怖いという気持ちもあります。


都市工学徒猪瀬舞概念」は、工学部都市工学科の竹麻呂さんが書いた猪瀬舞概念の各論です。

yuyusuki.hatenablog.com

私は前回のvol.1に「東大生猪瀬舞概念」という題名で「イノ先輩は東京大学に進学する」という主張をしたためた記事を寄稿したのですが、最後に東京大学イノ先輩同好会なる謎の団体をぶち上げて「地学や地理を扱う諸学科の学生や卒業生、地理や地学に詳しい人、あるいは学科の内実に詳しい人は大歓迎です」などと書いて会員を募集してみたところ、マジで入部者が現れて爆笑していました。爆笑。

都市工学科に進学したイノ先輩の学生生活に迫る12ページの論考です。



国内油田巡検」は、れんず先生が書いた国内の油田の概説+巡検記事です。20ページあります。1つの油田が恋アスでちらっと言及されたというだけで本編とあまり関係ない記事を20ページも寄稿するの、完全に連想ゲーム。
これはFindOurStarsよりもMicareの方に顕著ですが、この記事に限らず、読者を自分の得意なフィールドに引きずり込んで得意分野のパワーでビンタするような記事が多いんですよね。私も「まちカドまぞく vs. ウクライナ語警察」なんてのを書いてしまったので割と他人のこと言えないんですけど。



三県境 & 渡良瀬遊水地巡検報告」は、まーしー氏による極めて穏当な聖地巡礼記事になっています。安心して読んでください。



ALMA望遠鏡の命名企画に参加しました」は、これまた順当な記事になっています。kn1chtさんは前回と今回の2冊で3回寄稿してもらっているのですが、校閲担当的には「この人の記事に変な誤字脱字はまずないだろう」という安心感があり、大変助かっています。しかも編集長の仕事もやってくれているし、締切にめちゃくちゃきっちり間に合わせるし、とにかくすごい人です。

2021年秋、チリ・ALMA望遠鏡のアンテナ66台に付ける名前を募集するキャンペーンが行われました。 恋アスにちなんだ名前を付けようと、くじら座変光星「Mira」を提案した顛末をkn1chtがレポートします。



Koias Puzzle Hunt: 7 Puzzles for the Earth Science Club」は、エクトぷらずま氏によるパズルです。

もう一度言います。
パズルです。


パズルの中でも「パズルハント」という、謎解きに近い形式のもの、らしいです。解いてもらえれば作問担当者が喜びます。解答は次号掲載となっております。おかげで次号を何がなんでも出さないといけなくなりました




恋する小惑星考察年表」は、またしてもkn1chtさんによる記事です。氏は前回のvol.1で「星空描写からの「日時特定」入門」という記事を書いていたのですが、その方法論を使って恋アスの4巻までの日時を特定し年表にしてもらいました。マジで手間かかってます。おそらく、今後の恋アスの考察や二次創作に欠かせないマストアイテムになることでしょう。



拝啓、海の向こうの空へ」は、私が書いたノーベル物理学賞記念SSです。微かにナナチカ要素があります。


さらに、あおもみじ先生によるナナチカ探偵団の表紙絵を含め、3人のイラストが載っています。いい……

Micare vol.1

utkiraracircle.github.io

東京大学きらら同好会が満を持してお送りする、「きらら」をテーマにした合同誌です。「きらら」の合同誌という言葉から連想されるのは批評とかSSとかイラストとかでしょうが、現実には闇鍋としか言いようのない本が完成してしまいました。メロンブックスのタグが「まんがタイムきらら」「合同誌」「評論」「百合」「写真」「宇宙」「カメラ」「R・Python」「語学」「漫画」な時点でお察しです。完全オリジナルSFもあります。なんなんだよ。





初めてのきらら、どの作品がいいか」はタイトルの通りの記事です。オタク4人でオススメ作品を挙げるやつをしました。順当な「きらら」評論になっています。私もちょっと書きました。


立て看板制作報告@駒場キャンパス」もタイトルの通りです。サークルの宣伝をする立て看板を作ってキャンパスに設置したという報告を、プロマネののこ氏に書いてもらいました。
ちょうど、きら同の立て看の周囲には(政治的・社会的)主張の強い看板が多く、それが悪いとは思わないのですが、結果として砂漠に咲く花のような清涼感を漂わせています。


立て看板フォトギャラリー」はその立て看板の写真集です。屋外に設置されている蛇口の写真集も存在することですし、これくらい普通ですね。撮影者はkn1chtさんとれんず氏です。



みかーれ!」は、我らが東京大学きらら同好会の誇る神SF作家haxibami先生による、「きらら」と「東京大学」をテーマにしたSFです。キャラクターはきらら同好会内で考えたオリジナルキャラクターです。
SFを強く愛する氏が満を持してSFを執筆した——これは大変喜ばしいことです。まだ序章だけなのですが、早く続きが読みたいです。



もゆもゆに露出計を捧ぐ」は、れんず先生による電子工作記事です。またお前か。

時折真っ黒や真っ白な写真を撮ってしまう『ぎんしお少々』の塩原もゆるさんのため、シャッターを切る際に適切な光量を測れる「露出計」を作ろう……。 そう思い立ったれんず氏はいざ秋葉原へ。キャラクターのために電子工作をする一風変わった技術系記事です。

異常記事という感想しか湧かないのですが、これを異常認定してしまうと自分のウクライナ語記事も異常認定されそうなので、やめておきます。私の記事は異常じゃないので。



星屑テレパスからのモデルロケット入門」は、とにかく安定感のあるkn1chtさんによるモデルロケット入門記事です。マジで安定感ありすぎて校閲担当としては(以下略)



まちカドまぞく vs. ウクライナ語警察」は、まあ、説明文の通りなので。著者の私から追加でコメントすることは特にありません。ロシア語ガチ勢の全力をつぎ込みました。言語のオタクにまちカドまぞくとセットで送りつけたい。

まちカドまぞく6巻に登場するウクライナ語の文章に、ウクライナ語を学ぶ筆者が真っ向から向き合います。 原文の和訳、精読、文法と語法の解説、そして間違っている部分の訂正を通じて、まちカドまぞくのよりよい理解を目指します。
※ロシア語などスラヴ諸語の知識は必須ではありませんが、あればさらに楽しめます。


さらに、総勢6人によるイラスト・マンガが収録されています。ヤバい。買うしかない。みんななんで絵とか描けるん? すごすぎ

寄稿した文章の紹介+制作裏話

ナナチカ探偵団と不可能な虹

両親の家から戻る最中に、あおが新幹線から撮ったという山と虹の写真。イノ先輩の疑問をきっかけに、用事で不在のナナを除く地学部員たちはその写真に写る山を特定することに。
翌日、チカからその話を聞いたナナが「写真に不可解な点がある」と言い出して——

#FindOurStars vol.2に寄稿しました。恋する小惑星のナナとチカがメインの地理地学学園ライトミステリ短編、百合トッピングです。分量はB5で12ページ、だいたい1万字になっています。

私の人生初のミステリです。もっとも、昔からミステリのネタを考えるのが好きで——ミステリのオタクなら誰でも考えますよね?——、昔からトリックの作り方みたいなミステリ書き方講座はかなり読んでましたし、執筆してないだけで核心部分が完成しているようなネタはネタ帳にけっこう溜まってたりします。なので、私が本当の初心者かというと厳密にはそうでもないわけですが、文章として明確に形にしたのはこれが人生初です。

なんか小学生の頃にカス小説を書いたことがあった気もしますが、あれは西村京太郎に影響された私が鉄道を舞台に犯人と警察の攻防を書こうとして書けなかったやつで、謎とかトリックとか存在しないしミステリというよりはクライムサスペンスですね……(クライムサスペンスなんて呼べるほど上等なもんではないけど)
なんか、トレインジャック犯が橋の上で止めた列車から川にダイブするシーンがあった気がする。たぶん直前に「南紀オーシャンアロー号の謎」を読んでたんだろうなあ。



ミステリのオタク向けに説明すると、よくある専門知識もののミステリです。有名な例だとガリレオシリーズみたいな感じ。

オタクの「ナナちゃん主人公属性ある、探偵もの絶対に合う、誰か外伝作って」という声に共感して書こうと思ったのですが、ネタを考えるのが大変でした。
ナナちゃんを主人公にするなら、せっかくだし彼女の専門である気象の知識を謎解きに使うやつに……と思ったのですが、気象の知識がほぼない人間が気象ミステリ書くとか無理ゲーすぎるだろ。

結局、きらら同好会に所属する気象の有識者数名の助けを大いに借りながらかろうじてネタをひねり出したのはいいのですが、冷静に考えるとこれ、気象の知識があったら割とすぐ答えが分かっちゃうやつでは? 実際、完成版の作中でもナナちゃんは話を聞いただけで一瞬で推理しちゃってますし。
これはまずい。気象に詳しい人にも読んでほしいのに、謎がバレバレというのはミステリとして致命的です。ミステリの面白さの中核は謎が持つ魅力。バレバレの謎は魅力的でもなんでもないわけです。


かなり悩みました。
私が中学か高校の頃から愛読しているミステリ書き方講座を読み返したりして、なんとか謎の非自明度を上げようと考えたのですが、なかなか上手くいかなかったんですね。マジで困った。あ、この講座読んでみなさん是非ミステリ書きましょう。上げる先は「小説家になろう」でも「カクヨム」でもいいから。

素人、初心者のための具体的なミステリーの書き方


結局、気象のオタクから寄せられた知見をきっかけに突破口は見えたのですが……それでも単に一段階ひねっただけでで、ひねり方もあまり魅力的に感じなくて、あまり納得はしていません。

「謎→A」が自明だから別の真相を用意して「謎→Aじゃね?→Bでした〜」という構造にするのはいいのですが、だったら「Aじゃね?」から「Bでした〜」までの間にA説がダメというのを読者に納得させなければダメでしょう。「Aでは?→それだとこういう点が不可解→Bでした」なら(その不可解ポイントが後出しだと減点される可能性はあるにしても)まだ許されますが(ミステリオタクは可能性を否定されるたびに興奮する異常者です)、「Aでは?」から前触れもなく「Aじゃない証拠が出てきて、即座にBだと分かりました〜〜おしまい」はちょっと唐突すぎる気がします。
さんざん魅力的な謎と推理を展開した後の最後の一押しに使うならまあ許容されるかもしれませんが、気象に詳しい人にとっては「謎→A」が自明すぎて「AではなくB」しかミステリ要素がないわけで、必然的にこれがメインになってしまいます。それはちょっと……


まあ、Bという真相に意外性があるなら、意外性すらない「謎→A」ストレートよりは遥かにマシですが。なお、今回の場合、Bという真相の意外性すら(気象に詳しい人にとっては)確信できるほどではなかったので、徹底的にミスリードを狙っていくメソッドを使いました。ちゃんとできてるかは知らん。あるいはミスリードが露骨すぎた可能性もあります。


総評すると、謎の面白さや不可解さ、トリックの意外さという観点から言うと、この作品はかろうじて赤点回避かなあ……私が名作ミステリ読みすぎて眼高手低になってるという側面は間違いなくありますが。


ただし、まあ謎や仕掛けや真相の明かされ方が少々アレという部分以外に関しては(いやそこ一番大事じゃんというのは置いておいて)、ミステリオタクとしての全力を素人なりに出し尽くしたつもりです。愛と熱意は込めました。特に推理パート。とある読者さまから「めっちゃしっかりミステリの味付け」との評価を頂いております。味だけで中身は……とか言っちゃダメ
まあ、あれですよ、日常の謎だから! ライトミステリだから! (日常の謎やライトミステリというジャンルは謎のしょぼさやミステリとしての完成度の低さに対する免罪符ではありません)

やっぱミステリは好きなだけあって割と書くのが楽しかったです。なんなら推理パート書いてるときは時速1500字出てましたね。どれだけ調子がよくても時速1000字が限界の私としては明らかに爆速です。


あと、「トリック」を実際に実現できる条件を探すのにめちゃくちゃ苦労しました。分刻みの時刻表トリックが好きなオタクがこういうことやると、時間にして1分単位、角度にして1度単位の無駄な調整を始めてしまうんですが。鉄道と地理と天文と気象を組み合わせた究極の地理地学ミステリ……
しかも最悪なことに、その綿密な調整は作中で一度も言及されません。言及がないのが物語上自然なので仕方がないんですけど、もったいないと思ったので後書きに「ネタバレ考証」として書きました。ネタバレ部分の字がめっちゃ小さくなってて笑う。




3日の11時に書き終えたのですが(一応締切は2日だったのでちょいオーバー)、それから組版作業まで時間的な余裕があったので、気象有識者を含めたオタク各位からフィードバックをもらい、修正して作品の品質を上げることができました。マジで感謝してます。



ちなみに、気象ミステリには「蝶が舞ったら、謎のち晴れ」という前例があります。作者は東大で地球惑星科学の博士号を取った人らしく、まあそうだよね……という気持ちに。

拝啓、海の向こうの空へ

今年の春に星咲高校を卒業した七海悠は、その後進学して気象学を学んでいた。10月上旬のある日、そんな彼女のもとに、あるニュースが飛び込んでくる。
ノーベル物理学賞に眞鍋淑郎氏」

#FindOurStars vol.2に寄稿しました。ノーベル物理学賞2021記念SSです。時事ネタです。pixivで全文が読めます。一応、微ナナチカです。

www.pixiv.net

本来の締切が10月2日で、ナナチカ探偵団を書き終えたのが3日。ノーベル賞が5日夜、ネタが降ってきたのがその数時間後、着手が7日、執筆を進めつつ参考文献を拾ったのが7日の夜、初稿を上げたのは9日の1時半、改稿してほぼ今の形になったのが9日の5時。人々のレビューを経て修正したのが9日の20時半、投稿が10日の0時、Twitterでの告知が10日の18時。

字数が少ない+主人公が考えてるだけ+物語自体の展開は雑+小説書くの多少慣れた、の4コンボにより自分比で爆速執筆と相成りました。


エモに全振りしました。エモい気分になってくれると嬉しいです。
大学に進んでもナナチカしてくれ、という祈りを込めて。たぶん大学生ナナチカを書いたほとんど唯一のSSな気がします。

まちカドまぞく vs. ウクライナ語警察

まちカドまぞく6巻に登場するウクライナ語の文章に、ウクライナ語を学ぶ筆者が真っ向から向き合います。 原文の和訳、精読、文法と語法の解説、そして間違っている部分の訂正を通じて、まちカドまぞくのよりよい理解を目指します。
※ロシア語などスラヴ諸語の知識は必須ではありませんが、あればさらに楽しめます。

utkiraracircle.github.io

Micare vol.1に寄稿しました。

もともとはMicareの方に寄稿する予定はなかったのですが、10月3日にナナチカ探偵団を書き終え、一応締切は過ぎているけど組版までは余裕があるということで、前から考えてた企画を急遽実行に移すことにしました。

大学図書館1(駒場キャンパスの駒場図書館)に置いてあったウクライナ語の本とまちカドまぞく6巻とインターネットのウクライナ語辞書を付き合わせて頑張り、勢いで執筆し、5日14時に初稿を上げました。なんというか、早くね? ちなみにウクライナ語を学ぶのは人生初ですが、ロシア語はだいぶガチってるので割となんとかなりました。

その後、7日の19時に大学図書館(本郷キャンパスの総合図書館)に行って、閉館する22時半までウクライナ語と格闘し、さらに加筆修正しました。本郷の方にはユーラシアセンターというところが出した巨大なウクライナ語辞典が置いてあって、マジで助かりました。ちなみに、大学に向かう途中でナナチカ探偵団の修正やノーベル賞SSの執筆に必要な参考文献も拾いました。22時半なんて時間まで大学にいたのは初めてだったのですが、その後駅までふらふら歩いてたらかなり巨大な地震に遭遇し、 無事地下鉄が止まったので歩いて帰ったというオチ。

本郷で借りた「ニューエクスプレスプラス ウクライナ語」を読んで最終チェックをしていたらミスが発見されたので、それを修正して9日4時に脱稿しました。




Re:VIEW+InDesignウクライナ語を組んだのは初めてでしたが、今までキリル文字組版にさんざん苦しんだ経験から、おそらくウクライナ語部分に適切なフォントを指定すれば大丈夫だろうと判断しました。
わざわざreview-ext.rbでキリル文字専用命令を入れ、InDesign組版に備えることにしました。一括でフォントを設定できるようにタグを作っておいたわけです。このためにウクライナ語用スタイルが用意されるわけですね……




さて、うちのサークルではRe:VIEWInDesignで本を組んでいるのですが、組版やデザイン全般を1人で担当するあをもみじ先生というワーカホリックがいらっしゃいます。2冊同時進行とかマジで過労で倒れるんじゃない?

で、なぜかInDesignに記事をインポートしたときにquoteに入れたウクライナ語の部分が改行されておらず、画面配信を見ながらキリル文字が読めない先生にボイスチャットで指示して改行を入れてもらいました。人に背中を掻いてもらうみたいなもどかしさがありましたね。マジで貴重な体験だったと思います。「あー、2行目真ん中の3みたいな文字(з)の前にあるピリオドで改行して」じゃないんですよ。対面でやれたらまだよかったんですけどね。




さて、無事入稿できたら、告知のことを考えなければなりません。もともとネタを考える段階からTwitter映えはかなり意識していましたし、Twitterに投稿してもらう記事の説明文もTwitter歴7年のセンスをフル活用することで伸びるように仕向けました。あとは7年かけて育ててきた6000フォロワーアカウントのパワーを利用し、無事そこそこ伸びました。


こういう、ニッチなことに異常な本気を出すという芸でしか笑いを取れないんですよね、私。






入稿までの振り返り

……なんというか、ノーベル賞SSとまぞくウクライナ語記事とナナチカ探偵団の修正を全部並行してやったの、頭かなりおかしくない? 暴走執筆マシンとは言い得て妙でしたね……

校閲

勝手に校閲係を自称し、合計150ページ弱の校閲をやりました。時間なくてヤバかったし、全部十分に確認できたわけではないですが。この分量を締切前の修羅場で一文字一文字丁寧に読むの普通にヤバくて発狂しました。この読み方をすると、文字で埋まってるページなんか読むのに普通に数分かかりますからね。

その途中でいろいろ致命的なミス(見出しが見出しになってなくて、謎の単語が文中に混ざってる状態だったとか)があり、マジでやっといてよかった〜〜という気持ちになりました。でも結局目次とか図のキャプションとかそういう見逃しポイントに誤植が大量に紛れてて、最悪です。校閲係としては大変悔いの残る結果になりました。

当日まで

Micareと#FindOurStarsそれぞれの編集長である500mL氏とkn1chtさんにwebサイトの更新をしてもらったり、告知用の画像や文章を考えてもらったりしました。私は一応、自分の分は自分で考えましたが。
ナチュラルにみんなプログラムいじれるの怖くない? みんなナチュラルにGitHubで直接原稿上げてくるのもそうだけど……ここコンピュータのサークルじゃなくて「きらら同好会」だよ……?

当日

10月24日、会場は京急蒲田大田区産業プラザPiO。設営は担当の人(サークルチケットが2人分だった)に任せ、一般入場で入りました。

適当にぶらぶらして良さそうな同人誌を大人買いしたり——ほぼ全て小説と評論でした——、来たオタクと「次のコミティアでサークル参加側として対よろです」みたいな話をしたり——数日前に同人熱が高揚してサークル「ナヴァストーケ」を設立してしまったので——、筑波大学でオタクサークルを新設した人のアニメみたいな設立秘話を聞いたりしました。

www.fabon.info


そしたら、なんかMicare vol.1が会場頒布分完売しててビビりました。会長が爆死にビビってたから割と売れて良かったね〜〜って思ってたんですけど、思ったより売れてたんですね。FindOurStarsもほぼ完売でした。本当はMicareもまだ残ってたんですが、そっちはメロンブックスの委託分ですし、boothとは違ってメロンブックスは販売数があらかじめ決まってるので。


なんだろう、東大というネームバリュー……? 想定外の大好評の理由が分からないと突然爆死しそうで怖いんですけど。


ちなみに、ここから(当選すれば)コミケという伏魔殿が待ち構えています。どれくらい増刷すべきなんでしょう……。あまりたくさん印刷して在庫抱えすぎるのもヤバいけど、足りなくなるのも敗北ですし。どれくらい売れるのかなんも見通せないのが困りますね。「想定外の大好評の理由が分からない」というのが効いてます……




冷静に考えると「大好評すぎてどこまで刷ればいいか分からない」って信じられないくらい贅沢な悩みですよね。



その後は、メロンブックスへの宅配便を梱包してるオタクを眺めたり、結局シフトに入ったけどやることが何もない売り子のコスプレをしたりしました。

アフターイベント


じゃんけん大会、めっちゃ大量に景品があってすごかったです。なんなんだろう、みんな軽率にコミック数冊どころか十冊くらい貢ぐし、怖い。

おかげで終了が30分後ろにずれ込みました。私はオタクがもらったコミック大量セットから「またぞろ。」の1巻を恵んでもらいました。

その後の話

会場から直接メロンブックスに送ったMicare vol.1と#FindOurStars vol.2は無事先方に届き、流通などの準備も終わったようです。ちょうど29日の夜頃に着弾報告がちらほら見られるようになりました。Micareは秋葉原メロンブックスでちゃんと売られているのが確認できたんですけど、FindOurStars2は店舗在庫がないらしく少し不安でした。ちゃんと流通しているようで、なによりです。


今後の話

Micare vol.2はおそらく割とすぐ書くことになると思います。私も当然寄稿します。仮に受かってもコミケよりは後になりますが。ネタは「きらら」全体から探せるので、まあなんとでもなるでしょう。

また、コミケに受かってたらワンチャン新刊を出すかもしれません。私は寄稿しませんが、いい本になると確信しています。別にサボったり休んだりするわけじゃなくて、単に私は文章しか書けないというそれだけの話です。


そして、悩ましいのは#FindOurStars vol.3の方です。4ヶ月間隔で2冊も出して、題材も恋する小惑星に限られるという無茶っぷり。そろそろ寄稿者たちのネタが尽きつつあり、にもかかわらず本編は2月くらいまで休載。公式からの供給もないのにネタを錬成しろって無理がありますよ。
それでも、出さないという選択肢はありません。パズルの解答はvol.3に載せるって書いちゃったんですからね。

とりあえず、来年3月予定の動画工房オンリーにはたぶん出展する気がしますね。今年6月の初サークル参加でお世話になったイベントですし。
それまでに#FindOurStars vol.3が出せるかは……なんとも言えないところです。



ところで、ナナチカ探偵団は「ナナチカ探偵団と〜」という形式でタイトルを統一できるようにしています。だから、私個人としてはネタさえあれば続編だって問題なく書けます。が、ネタがない。1作目ですらめちゃくちゃ難産だったのに、さらにミステリのネタを出せと言われても無理があります。
別に地学や地理のネタじゃなくてもいいんじゃないか、というのはちょっと思ったりしますが、でもそれ、ナナチカ探偵団でやる必要ある?

そもそも時系列で考えたときに1作目から進めるしかないわけですが、どこだよ。原作あんま進んでないのに。



……モンロー先輩要素がちょっと薄いんですよね、うちの合同誌。桜先輩の方は桜先輩ガチ勢にイラストをいろいろ寄稿してもらってるんですが。次に小説を書くとしたらそこかなあ……


あるいは評論でもいいですが、評論は評論でネタがないんですよ。私は地学や地理に全然詳しくないので。vol.1とvol.2を読み返しても、私以外の寄稿者はほぼみんな地理か天文か地質か気象の話しか書いてないという恐ろしい事実が発覚しただけです。

原点に帰って「恋する小惑星」という作品のレビューでもするか……?


あと、次回以降おそらくkn1chtさんから#FindOurStarsの編集長を譲り受けることになると思います。Re:VIEWは中高の頃から普通に使ってたしRubyistだからreview-ext.rb普通に書けるし技術的な問題はないけど、私マジでマネジメント能力ないんだよな……大丈夫かな……








やっていきましょう。
同人って楽しいね。

【豊田商事】オイショ!ロシア語訳【この世の終わりみたいな朝礼】

月が変わって1日になったからか、TLに豊田商事コピペがたくさん流れてくるな……



オイショ! \オイショ!/ オイショ! \オイショ!/ オイショ! \オイショ!/ オイショ! \オイショ!/
今月はね!一日からね!飛ばしていきますよ!いいっすか!それには今日!新規面談もろうたら!一本目粘って!とにかくお客さんと勝負して!今日一日ね!目一杯やってください!




www.youtube.com





……ん?
























🤔








豊田商事朝礼コピペをロシア語にするなんて……私のような常人には思いつかないセンス……







しかし……これはどこからどう見ても明らかな機械翻訳……





まさか……「不満ならお前のロシア語力を見せてみろ」という挑戦状なのか……?








「やってみせろよ、マフティー!」
「何とでもなるはずだ!」
ガンダムだと!?」









鳴らない言葉をもう一度描いて

研究社露和辞典、これならわかるロシア語文法








赤色に染まる時間を置き忘れ去れば







Ойшо! \Ойшо!/ Ойшо! \Ойшо!/ Ойшо! \Ойшо!/ Ойшо! \Ойшо!/
В этом месяце! С 1-го! Идём на полной скорости! Понятно!? Для этого сегодня! Если у вас будет совещание с новым клиентом! Не сдавайтесь на первом совещании! Прежде всего боритесь с клиентами! Сегодня целый день! Прилагайте все силы!



ロシア語のミスはご愛嬌。まあ、さすがに機械翻訳には負けん。






Ойшо! \Ойшо!/ Ойшо! \Ойшо!/ Ойшо! \Ойшо!/ Ойшо! \Ойшо!/


Ойшо! \Ойшо!/ Ойшо! \Ойшо!/ Ойшо! \Ойшо!/ Ойшо! \Ойшо!/



Ойшо! \Ойшо!/ Ойшо! \Ойшо!/ Ойшо! \Ойшо!/ Ойшо! \Ойшо!/







終 конец
制作・著作
ふぁぼん











解説

蛇足。

「1日から」

これで「いっぴ」って読むらしい。ビジネスの世界のスラングだね。日付の1日なので、деньではなくчислоになる。

「飛ばしていく」

どう訳せば適切なニュアンスになるのか分からずほとほと困り果てたので、苦し紛れに「全速力で行く」と訳した。ちょっと比喩的な表現になるけど。後で「全力を出す」が出てくるし、訳し分けないといけない。

「いいっすか」

「分かったか?」のニュアンスで訳した。「準備できてるか?」ならГотовы? という表現にもできる。

「それには」

この場合「前述の目的を達するためには」という意味なので、для этогоを採用。一応поэтомуなどの「だから」系統は使わなかったが、正直大して意味が変わらん気もする。

「新規面談もろうたら」

なんて訳せばいいかマジで分からん。「面談」という言葉にもビジネス特有のニュアンスがある気がするし。
とりあえず「みなさんに新しい顧客との打ち合わせがあったら」にした。これだと「もらったら」のニュアンスが出ないが、致し方なし。

「1本目粘って」

「1本目」がかなり分からない。とりあえず「今月1つ目の面談」と解釈することにした。
さらに「粘って」もどう訳せば適切なニュアンスになるのか分からずほとほと困り果てたので、諦めて「引き下がらない」とかなり意訳した。この後に「お客さんと勝負して」とあるので、まあこれでも不自然ではない、はず。

「とにかく」

この場合は「何よりもまず、ひたすら」って雰囲気だと感じたのでпрежде всегоを採用。自信はない。

「今日1日ね!目一杯やってください!」

とりあえず「目一杯やる」はприлагать/приложить все силыを採用。「今日1日」は「今日、1日中」と解釈しсегодняとцелый деньにした。で、こういうときに問題なのは完了体か不完了体か、だが……持続する動作だし不完了体でいいんじゃないかな。知らんけど。マジで動詞の体もロシア語4年やってきてなお全然分からん。今後分かるようになるかも怪しい。

感想

こういう口語的な文章が訳すの一番難しいというのは古事記にも書かれている有名な事実。あと、そもそもお客さんと戦うな。さすが伝説の詐欺会社……



thinking faceの絵文字(🤔)はTwitterのやつを借りた。CC-BY 4.0なのでこうして書いている。

GitHub - twitter/twemoji: Emoji for everyone. https://twemoji.twitter.com/