:::note info
最後まで読まないと結論が載ってない系の記事です
:::


ExcelやCSVをプログラムで処理したいケースはよくあると思います。
みなさんはどうやって実装しますか？



人によってアプローチは異なると思いますが、

CSVといってもテキストファイルの処理なので、大抵の言語で実装できるでしょう。

CSVなので、行ごとにカンマで区切って処理すればいいだけです。

ファイルを一度全部読み込んでから行ごとにループ処理するアプローチがありますが、

メモリ効率が悪くファイルサイズが大きくなると対応できないため、

行ごとに順番に読み出していく処理が必要になります。



Pythonだと標準モジュールにCSVモジュールがあって、

普通にfor文で1行づつ処理できるのでサクッと書きたい時には重宝します。

今回はTypeScriptで同様の書き味ができるようにしてみたので紹介です。



## Node.jsのreadline



Node.jsにはストリームを行単位で取り扱うことのできる**readLine**モジュールが標準で提供されています。

https://nodejs.org/api/readline.html



Node.jsは非同期のイベント駆動なので、基本はイベントにコールバック処理を定義する形になります。

readlineの**createInterface**を使うことによって、lineという行の読み取りイベントを受け取ることができるので、

1行の処理はここに書くことができます。

↓こんな感じですね。
```typescript
import fs from "fs";
import readline from "readline";

const rl = readline.createInterface({
 input: fs.createReadStream(path),
 crlfDelay: Infinity,
});

rl.on("line", (line) => {
 // 1行分のデータに対してなんかする
});
```


サクッと書くだけでいいならこれでいいのですが、

イベントのコールバックに処理を書くため、読み取り結果を外のスコープに返すときにちょっと面倒だったりします。

全部を読み取った後にPromiseで返すことはできますが、全行を保存するバッファを用意しないといけないので趣旨からは外れてしまいます。



## async iterator



少し脱線します。

JavaScriptにはfor of という構文がありますよね。


```typescript
for (const element of array) {}
```

arrayが配列の場合、elementには要素が順番に渡されるという仕様ですが、

**Symbol.iterator**というメソッドが実装されていれば配列以外でもこの構文を使うことができます。

※配列やMapなどの反復可能なオブジェクトには標準で実装されています。

 詳しくは以下が参考になります。

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Symbol/iterator

https://ja.javascript.info/async-iterators-generators#ref-2055



そして、**Symbol.asyncIterator**が実装されている場合は非同期に反復処理ができます。

 つまり、for await of構文が使えます。

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/for-await...of

https://ja.javascript.info/async-iterators-generators#ref-2056



for await of の構文はこんな感じです。
```typescript
for await (const element of asyncArray) {}
```
非同期に反復可能なモノにたいして使うことができます。



使うケースが限られているのもあってイメージがつきにくいのですが、

readlineの**createinterface**は**asyncIterable**（async iteratorが実装されている）なオブジェクトを返してくれるので、

このfor await ofを使うことができます。

※Node.js12とかからだった気がする



## for await of を使って1行ずつ処理する



こんな感じです。

```typescript
import fs from "fs";
import readline from "readline";

const rl = readline.createInterface({
 input: fs.createReadStream(path),
 crlfDelay: Infinity,
});

for await (line of rl) {
 // 1行分のデータに対してなんかする
}
```


ふむふむなるほど？

確かにfor await of でスッキリ書けるようになってるけど、

スコープ外にデータを持ち出せないのは変わってなくない？



そうです。ただfor await of で処理できるだけでは旨味がありません。

この処理を**async generator**で包むことで真価を発揮します。



## async generatorな関数にする



https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/AsyncGenerator

https://ja.javascript.info/async-iterators-generators#ref-2058



その名の通り非同期なジェネレーターです。

詳しいことは省略しますが、ジェネレーター内では**yield**が使えるので、

任意のタイミングで値を返すことができます。



さきほどの処理を**async generator**で包むとこうなります。

```typescript
const asyncReader = async function* (path: string): AsyncGenerator<string[]> {
 const rl = readline.createInterface({
 input: fs.createReadStream(path),
 crlfDelay: Infinity,
 });

 for await (const line of rl) {
 // 1行ごとの処理
 const result = line.split(",")
 yield result;
 }
};
```


csvなのでカンマ区切りのデータを配列に分解してから呼び出し元に戻しています。

使用側はこうなります。

```typescript
const reader = asyncReader(path)

// next()で1行ずつ読み出し
(await reader.next()).value;

// for await of も使える
for await (const line of reader) {
 console.log(line[0])
};
```


ただのサンプルですが、CSVを読み取るプログラムとデータ処理を分離することができましたね。

**yield**で行ごとにデータを返しているため、バッファで全体を保持する必要がなくメモリ効率がよくなります。

 ※1行分のデータが重い場合はこの方法では解決できませんが、、



## CSVの改行を正しく扱えない問題



1行ずつデータを処理できるようになりましたが、

readlineの行イベントをそのまま処理しているため、CSVのデータ内（セル内）に改行があった場合対処できません。

CSVの仕様としては、ダブルクォーテーションで囲われた文字列内の改行がデータ内の改行として扱われる仕様なので、

読み取るプログラムを書く場合はこれを考慮する必要があります。

readlineはCSVに特化したものでもないので、自分で処理を書くことになります。



さきほどの、**async generator**関数です。

**yield**してしまうと呼び出し元にデータが返ってしまうため、

それより前段で判定して次の行データを取得する必要があります。

```typescript
const asyncReader = async function* (path: string): AsyncGenerator<string[]> {
 const rl = readline.createInterface({
 input: fs.createReadStream(path),
 crlfDelay: Infinity,
 });

 for await (const line of rl) {
 if (データ内改行がある場合) {
 // 次の行も取得してまとめたい
 }
 yield line;
 }
};
```


**async generator**関数で使える**next()**を使いたくなりますが、

readlineの**createInterface**はジェネレーターではないので残念ながら使えません。

```typescript
 for await (let line of rl) {
 if (データ内改行がある場合) {
 // next()で次の行を取得したいが、できない
 line += await rl.next()
 }
 yield line;
 }
```



### そうだ！もう1つジェネレーターを挟もう！



私が思いついた解決策は1行分の文字列を**yield**するだけのジェネレーターを作成することでした。

```typescript
const asyncReader = async function* (path: string): AsyncGenerator<string> {
 const rl = readline.createInterface({
 input: fs.createReadStream(path),
 crlfDelay: Infinity,
 });

 for await (const line of rl) {
 yield line;
 }
};
```


そして、呼び出し元に返す関数を別で作成します

```typescript
export const lineParser = async function* (path: string): AsyncGenerator<string[]> {
 const reader = asyncReader(path);

 for await (let line of reader) {
 while (isNeedNextLine(line)) {
 line = line + "\n" + (await reader.next()).value
 }

 yield values = line.split(",");
 }
};

const isNeedNextLine = (line: string): boolean => {
 const matched = line.match(/"/g);
 // クォーテーションなしはセル内改行なし
 if (!matched) {
 return false
 }

 // クォーテーションが奇数＝セル内改行あり
 return matched.length % 2 === 1;
};
```


データ内に改行がある場合、対になっていないダブルクォーテーションが存在するので、

1行に含まれるダブルクォーテーションの数で判定しています。

読み取りをジェネレーターで包んだため**next()**が使えるようになったので、

改行が含まれる限りwhileで繋げるように処理を書いています。

これで、データ内の改行を考慮することができるようになりました。

※改行を繋げた結果の文章が長すぎるとメモリオーバーする可能性はありますが、、、



## もっとTypeScriptっぽく書きたい。



先ほどの処理を使うと、読み取り処理はこうなります。

```typescript
const parser = lineParser(path)

for await (const line of parser) {
 console.log(line[0])
};
```


カンマ区切りで配列にしていたので、個々の値を取得する場合は要素を指定する必要があります。

文字列であるということがわかっているだけで、全くTypeScriptみを感じませんね。

少し手を加えてTypeScriptっぽくしていきます。



まず、カラム定義ファイルを用意します。

大抵の場合、読み取りたいファイルのカラム定義は決まっていると思います。

1列目にID、2列目に名前、といった感じですね。

決まっているのであれば、TypeScriptのファイルで定義してみましょう。



サンプルのCSVはこちらです



|fire|	water	|grass|
|--|--|--|
|Charmander	|Squirtle|	Bulbasaur|
|Charmeleon|	Wartortle	|Ivysaur|
|Chalizard	|Blastoise|	Venusaur|

このCSVに対し、どの列にどんな値が入っているかを定義したいので、
カラム定義のコードははこうなります。

```typescript
const StarterPokemonColumn = {
 fire: 0,
 water: 1,
 grass: 2,
} as const;
```


これを先ほどの**lineParser**に渡せるように変更します。


```typescript
type LineObject<T> = Record<keyof T, string>;

export const lineParser = async function* <T extends { [key: string]: number }>(
 path: string,
 columns: T,
 useHeader = false
): AsyncGenerator<LineObject<T>> {
 const reader = asyncReader(path);

 if (!useHeader) {
 await reader.next();
 }

 for await (let line of reader) {
 while (isNeedNextLine(line)) {
 line = line + "\n" + (await reader.next()).value
 }

 const values = line.split(",");

 // 渡されたカラム定義に従ってオブジェクトを作成する
 const lineObject = Object.entries(columns).reduce(
 (obj, [key, position]) => ({ ...obj, [key]: values[position] }),
 {} as LineObject<T>
 );

 yield lineObject;
 }
};
```

呼び出し側はこのように書くことができます。

```typescript
const parser = lineParser(path)

for await (const line of parser) {
 // lineに対し、補完が効くようになる
 console.log(`noEvolved fire:` ${line.fire})
}
```

line[0]とやっていることは変わりませんが、 
どの列が何の値かを常に参照しながらプログラムを書くのはしんどい上に、 
ミスがあっても実行時まで気づけないという問題があります。 
このように自分でカラム定義を書くことで、TypeScriptっぽい書き味になりました。 

## まとめ

以上、TypeScript（Node.js）でCSVを1行ずつ処理する、でした。 
他の人の「自分ならこうする！」を聞いてみたいなと思います。

以下、最終的なコードです。

```typescript
import fs from "fs";
import readline from "readline";

export type LineObject<T> = Record<keyof T, string>;

const asyncReader = async function* (path: string): AsyncGenerator<string> {
 const rl = readline.createInterface({
 input: fs.createReadStream(path),
 crlfDelay: Infinity,
 });

 for await (const line of rl) {
 yield line;
 }
};

export const lineParser = async function* <T extends { [key: string]: number }>(
 path: string,
 columns: T,
 useHeader = false
): AsyncGenerator<LineObject<T>> {
 const reader = asyncReader(path);

 if (!useHeader) {
 await reader.next();
 }

 for await (let line of reader) {
 while (isNeedNextLine(line)) {
 line = line + "\n" + (await reader.next()).value
 }

 const values = line.split(",");
 const lineObject = Object.entries(columns).reduce(
 (obj, [key, position]) => ({ ...obj, [key]: values[position] }),
 {} as LineObject<T>
 );

 yield lineObject;
 }
};

const isNeedNextLine = (line: string): boolean => {
 const matched = line.match(/"/g);
 // クォーテーションなしはセル内改行なし
 if (!matched) {
 return false
 }

 // クォーテーションが奇数＝セル内改行あり
 return matched.length % 2 === 1;
}
```

Node.jsでCSVを1行ずつ処理する（async generator）

mishio

今年の4月から、現在の職場で「SREチーム」という枠で働くようになりました。 SREというとシステム運用やDevOpsの全般を面倒見るイメージを持っていたのですが、 既存のシステムはその開発チームが運用管理しているのもあって、 自分はまったく運用作業をしていません。 各システムのモダナイズを進めるにあたっての、開発チームへの技術フォローや、 技術検証の取り組みなどが主な自分の仕事になっています。 <h2 id="h46e3a4c781">SREとしてチームにどう関わるか</h2> 「SREチーム」という名を冠しているので、開発チームからは意思決定を求められることが多くなります。 使用する言語・フレームワークなどは職場内で統一しようとしているものがあるので問題なくフォローできたりするのですが、 もう少し細かい範囲、例えばディレクトリ構造やユニットテストの書き方について相談を受けると、 「開発チームで考えればいいのでは？」 「そうはいっても丸投げだと標準化が進まない」 という思いが湧いてきて悩んでいる日々です。 世に言うSREの仕事として正しいかは別として、 ああしろこうしろ、とSREが指示する方針だと開発チームは楽しくないでしょう。 一方で、指針となるプロジェクト・サービスも用意できていないので、 新しい言語で開発しろとだけ言われても開発者は途方にくれると思います。 <h2 id="h6096b08d3f">CI/CDの構築とSRE</h2> ここ数ヶ月はSREと開発チームの境界線、住み分けについて考えていますが、 直近で「CI/CDの構築について」聞かれる機会がありました。 「CI/CDをやりたいので相談したいです」 と声をかけていただき、これは確かにSREっぽいなと思いながら詳細を聞きました。 相談内容はこんな感じです。 ・開発チームとして何をすべきか ・CI/CD環境について教えてほしい ・SREチームに頼めば全部やってくれるのか 最初はやりたいことをヒアリングして、 CI/CD環境をSREチーム側で用意するイメージをしていましたが、 話を聞くとここでも開発チームと調整が必要なことに気づきました。 まず、CI/CDについてはGitLabを使用している以上、GitLab CIを使うことになります。 GitLab CIで何かをする上で、いくつか準備・設定すべきことがありますが、 <ol><li>GitLab Runnerのインストール、登録</li><li>CIの設定ファイル（.gitlab-ci.yml）の追加</li><li>CIの設定ファイルに動かすスクリプトを書く</li><li>デプロイ先の環境作成</li></ol> ざっとこんな感じになると思います。 デプロイしないなら3までですし、ContainerRegistryやPagesを使うならもう少しやることは増えますね。 この中で、SREチームがやるべきこととして明確なのは、1・2・4だと思います。 開発者目線から考えると、CIのスクリプト（テストとか）を書くだけで実行できる環境になっていると、 かなり開発のみに集中できる印象です。 なので、SREチームとしては、CIの設定ファイルの雛形やサンプルを提供し、 開発チームに書いてもらったものをレビューしてコミットする、という流れを考えました。 調整というほど大仰な作業ではないですが、 ブランチ運用との連動だったり、CIの実行環境についてだったりを話しているうちに新たな要件が湧いてくるので、 丸投げする・されるものではないなと感じています。 また、CIの設定ファイルは基本的にソースファイルと同じリポジトリで管理する必要があるので、 丸投げされたときにSREチームがコミットするのかどうかも相談しないといけません。 <h2 id="h1670d427ea">開発者のスキルとCI/CD</h2> 自分が一番モヤモヤしているのはここです。 SREチームがうまく開発チームと連動していい感じに責務分担できたとして、 CI/CDに関するナレッジはどこに溜まるのでしょうか？ 開発チームのメンバーに知見として蓄積されていかないのではないでしょうか？ 自分は未経験でこの業界に入りましたが、 2年目の時に小さな開発チームの中で、GitLabの構築からCI/CD環境の整備までを担当する機会があり、 そこで幅広い知識を身につけることができた経験があります。 昨今ではCI/CDはコンテナ環境で実行されることが多く、 Linuxについての基礎的な知識からDockerに関する知識など、運用にあたって様々なスキルが要求されます。 難易度は高いですが、1段目線を上げることのできる機会にもなり得ると思いますし、 それゆえに「SREチーム」がその経験を奪ってしまう構図を少し残念に感じています。 きっと観点がずれていて、SREチームは開発組織としての効率化やオペレーションの最適化を考える上で必要なのだろうと感じています。 ただ、業務で得られる経験値はSREの分野はとても大きいので、それをどうやって組織に還元することができるのかも悩ましいです。

SREとCI/CD

仕事でAWSを触るようになったので、取得してきました。 <h2 id="h39a4e89f57">点数</h2> 768/1000点（720点以上で合格です） ぎりぎり。。 <h2 id="h8e062f0e85">勉強について</h2> 2週間ほど。 65問の練習問題（Udemy）を3セットやりました。 解くのに1時間・解説見て調べたりするのに1時間ぐらいです。 最初にYouTubeの動画でサービスをざっくり把握したのがよかったです。 あとは、勉強した内容がそのまま業務で活用できたので、 業務を通して自分の知識に落とし込めたのかなと思います。 <h2 id="h6a45e3f004">問題について</h2> 練習問題より1段階難しかったです。 8月末から問題が新しくなったのですが、 周知のとおり、セキュリティに関する問題が多かったように感じます。 サービスを運営するにあたって、システムを守るための仕組みは理解しておきたいです。

AWS SAA 取得しました

先に結論を。 そんなん気にせずに読め！！ 先日、「ライトノベルってなんですか？」という質問を受けることがありました。 自己紹介をする機会があり、本読むのが好きで、ほぼほぼ小説、最近はライトノベルばっかり読んでいます〜 と趣味について語っていた時に受けた質問です。 ライトノベルも市民権を得て久しいと思っていましたが、 自分は比較的最近にライトノベルにハマった（学生時代、2010年代はまったく知らなかった）のもあって、 いわゆるラノベと小説の違いをあまり考えたことがありませんでした。 小説をほぼ読まない人からの質問だったこともあり、 その場は「小説よりも読みやすい」「挿絵のあるなし」と適当に答えてしまったのですが、 ライトノベルを定義するには浅すぎるので、自分なりに考えてみることにします。 ※特に歴史的経緯を追いかけたりするわけではなく、何の出典もありません。 　分析っぽい書き方ですが普通に感想も混じってます。駄文です。 <h2 id="h3e08b54a49">小説にとってのライトノベル</h2> 小説とライトノベル、と2つ並べて書いていますが、私はライトノベルは小説の一部だと思っています。 （SFやミステリといったジャンルとは違うベクトルのジャンル、カテゴライズになるので表現が難しいですが、 　ここではライトノベルは小説はの1ジャンル、という言い方をしてみます。） 図書館などでティーンズやジュブナイル、ライト文芸という名前で小説コーナーの一角に青少年向けの本が集められていたりしますよね。 出版社・レーベルが異なるだけで、あれらとライトノベルは大きな違いはないと思います。 小説の中でも比較的若年向けの読みやすい本たちが、マーケットの拡大に伴ってライトノベルと認識されていったのでしょう。 今では出版社各社に専用のレーベルが存在するので、 その本がライトノベルかどうか、はライトノベルとして売られているかどうかと言えます。 つまり、『ライトノベル』というジャンルづけをして売られている小説をそう呼ぶ、ということです。 <h2 id="h83bad2fa41">ライトノベルの特徴</h2> 「ライトノベルとして売られているからライトノベル」というのは破綻した論理ですが、 内容によってライトノベルが定義されるわけではないと思っています。 小難しい文調のライトノベルもあれば、会話が多く読みやすい一般小説もありますよね。 一方で、現代でライトノベルとして刊行されている作品にはいくつかの特徴があります。 <ul><li>表紙にキャラクターのイラストがある</li><li>本文中に挿絵が存在する</li><li>シリーズ化されている</li><li>一般小説と比較して文量が少ない（文庫版）</li><li>人気になるとアニメ化される</li><li>タイトルが長い</li></ul> 書店や図書館で見かけるだけの人も、共感できるポイントはあるかもしれません。 これらの特徴について、もう少し詳しく見てみましょう。 <h3 id="h851c2aaae4">ライトノベルとイラスト</h3> ライトノベル作品にとって、イラストはなくてはならない存在です。 著者と並んでイラストレーターの名前も表記されることや、「表紙買い」「神絵師」という言葉からも重要さがわかります。 小説も表紙に何某かの絵が描かれるものがほとんどですが、 小説のそれが抽象的な美術であるのに対し、 ライトノベルでは登場人物が描かれるかなり具体的なイラストになっています。 アニメ調のキャラクターが表紙に登場している＝ライトノベル、と言ってもいいほど、 「イラスト」はライトノベルという文化を構成する大きな要素です。 読者を読む前から惹きつける要素としてひと役買っているイラストですが、 一方で想像する楽しさを奪っているのでは？と個人的には思っています。 小説では登場人物の顔や雰囲気は、文中の表現から想像して楽しむものでしたが、 ライトノベルでは事前に提供されたキャラクターたちが頭の中で会話を繰り広げることになります。 淡い想像上の世界も良いよな〜と思う今日この頃です。 また、イラストだけでなくイラストレーターの存在もライトノベルを構成する1要素です。 ライトノベルのランキング本、「このライトノベルがすごい」でもイラストレーターのランキングが組まれるなど、 誰が書いたかではなく、誰が描いたかも注目されるポイントになっています。 後述しますが、アニメ等でメディアミックス展開される場合、 キャラクター原案は原作のイラストレーターがそのまま務めるケースも多いです。 イラストで残念なのが、基本的に可愛い女の子のキャラクターばかり、という点です。 もっと世界観がわかるようなディテールを表現して欲しい、と思います。 そもそもライトノベルの登場人物は女性キャラクターが圧倒的に多く（主観）、 必然的にそうなってしまうのは理解はできます。 学園もののラブコメにしろ、異世界ものやSFものにしろ、 男性は主人公と友人の2・3人いれば多い方という感想で、 ご都合主義な展開によって女性キャラクターが多数登場します（あくまで個人の感想ですが）。 男性が読者層の大半を占めているので、可愛い女の子出しとけばいいだろと言わんばかりの作品は少なくないのですが、 イラストレーターさんが仕上げると本当に魅力的になってしまい、一定数売れてしまったりするようです。 また、昨今のそうした状況から初巻の売上がイラストに左右されることもあるようで（要出典）、 基本的には作家がイラストレーターを選べないことから、「絵師ガチャ」という言葉が生まれているのも残念に思います。 <h3 id="ha74c1b6e85">ライトノベルと巻数</h3> 一般小説と異なる特徴その2が、ライトノベルの巻数です。 ライトノベルではシリーズ化されるケースが大半であり、 「シリーズ巻数が多い」＝「人気作品」という図式になっていると思います。 小説のシリーズ本も普通にありますが、 ライトノベルの場合はシリーズ化されることが原則と言えるほど小説とは一線を画しています。 タイトルは初巻から変更されることなく、末尾に2、3という数字がつけられるのも、 小説にはない文化かもしれません。 このシリーズ化前提の文化ですが、私は好きです。 小説でも続きがありそうな雰囲気のある終わり方だとテンションの上がるタイプでしたし、 気に入った作品に長く触れられることはシンプルに幸せだと思っています。 一方で、無理にシリーズ化しなくてもいいだろ、と思う作品も中にはあります。 1巻で単巻ものとして構成すればよかったのに、 シリーズ前提にした影響で話がまとまらないパターンや、 伏線回収できたのに無理に話を広げようとして停滞するパターンなどです。 もちろん作家さん・編集さんの意図があると思いますし、 ライトノベルという形態上ページ数もあまり多くないので妄言の域を出ません。 短い巻数であっても綺麗にまとまっている作品ももっと増えてほしいところですが、 後述するメディアミックス展開とかを考えれば致し方ないのかもしれません。 <h3 id="h5adbc8f192">ライトノベルとメディアミックス</h3> 突然ですが、アニメは見ますでしょうか。 一般小説と比較してライトノベルはアニメ化されるケースが多く、 最近は1クールの中に占めるライトノベルが原作のアニメが増えてきています。 私はアニメの続きが気になってライトノベルを読み始めたところからラノベ沼にハマった人間ですが、 今では推しのラノベのアニメ化発表を楽しみにする側になりました。 ラノベに限った話ではなく漫画でもそうですが、 原作で人気が出る→アニメ化→映画化、というのがここ最近の流れであり、 初巻の刊行前からメディアミックス展開を見据えた戦略を練られている作品も多くなったように感じます。 実際、ライトノベルではアニメ化の前にドラマCDという声優さんを起用したメディアミックスを最近は目にするようになりました。 （知らないだけでアニメ制作進行の1部なのかもしれません） ラノベの売上は一時期と比較すると落ちていると聞きますが、 メディアミックス効果により原作の売れ行きが伸びるケースもあり、 まだまだ可能性を残している市場だと思います。 アニメ化＝大成功、と言えるかというと必ずしもそうではなく、 巻数の少ないうちからアニメ制作が始まっているパターンは不穏な匂いを感じます。 焦らずにじっくり育てて欲しいですね。 最近だと「エイティシックス」という作品が緻密に制作されていて感動しました。 <h3 id="h0b7a02e539">ライトノベルのタイトルは長い</h3> ライトノベルというと、そのやたら説明的なタイトルが特徴という人も多いでしょう。 「◯◯なオレが〇〇で〇〇してみた」みたいなやつですね。 よくネタにされているのを見聞きします。 ラノベを読む自分も好みではないですし、一般小説のようなシンプルなタイトルの方が読みたくなります。 ただ、面白ければ気にしなくなりますしむしろ愛着のわく部分になるので あまり気にしなくていい要素かもしれません。 自分がこの手の作品に出会ったのは「やはり俺の青春ラブコメは間違っているのだろうか」という作品です。 高校生の時にタイトルを見て、こんなの誰が読むんだと当時は敬遠していましたが、 社会人になってから読んでめちゃくちゃにハマりました。 なぜ長いのでしょうか？ 私は、作品の属性を説明できるからではないかと考えています。 書店に並んでいる中から読む前の読者に訴求できるポイントは「イラスト」と「タイトル」です。 刊行ペースが一般小説よりも早いライトノベルは、ジャンルひとつとっても飽和状態なので、 読者の求めているレーダーに引っ掛けようとタイトルを工夫しているのでは、と思っています。 いくら中身が良くても、少なくとも手に取ってもらえなければ始まりませんし、 話題性という意味でも多少の効果はあるのではないでしょうか。 （もう二番煎じどころの話ではないですが） 作者が好き好んでこの手のタイトルをつけているわけではないと思います。 応募の結果賞をとった作品が長ったらしいタイトルになるケースもいくつか見てきました。 私は出版業界に明るくないので、どういう戦略で長いタイトルにしているのかはわかりませんが、 もういいでしょう、という声は届いていて欲しいと思います。 ただ、この説明的なタイトル、作品をある視点から要約できるという点は評価できるのではないでしょうか。 （タイトル詐欺なるものもありますが、ここでは触れません） 有名な文学作品や古典をどんな話なのかざっくり知りたい人がいたとしたら、 ラノベっぽい説明的なタイトルにするといい感じになるかもしれません。 例えば、森鴎外の『舞姫』。ラノベっぽいタイトルにすると、、 「エリート官僚が留学先で現地の踊り子と仲良く同居生活始めました」 とかでしょうか？ （後半の鬱展開でタイトル詐欺と言われそうです笑） <h2 id="hacc9cfa975">なぜライトノベルが好きなのか</h2> 長々と勝手な解釈でライトノベルについて書きました。 学生時代に小説一色で見向きもしなかったライトノベルを、なぜ貪るように読んでいるのでしょうか。 理由のひとつとして思うのが、アニメを好きになったから、ということです。 私は本を読む時、頭の中で登場人物が会話するようなイメージで物語を展開します。 あるときは誰かの視点になって物語に入り込んだり、あるときは3人称視点から眺めているような感覚だったり。 社会人になるまでに読んでいた小説は比較的現実に即したものが多かったのですが、 比較してライトノベルは現実離れした設定・人物像が多いです。 当時の私は、2次元の可愛い・かっこいいキャラクターを頭の中で再現できず、受け付けられませんでした。 それが社会人になってアニメを見るようになると、多少のぶっとんだ世界観や 2次元のキャラクターがスッと自分の中に入ってくるようになりました。 そこからは、ライトノベルを読み漁るのにそう時間はかかりませんでしたし、 今ではなぜ学生時代に読んでいなかったのかと後悔するぐらいです。 好きになる素養は元々あって、読めるようになってその面白さに触れることができるようになったのでしょう。 ライトノベルだから好きなのではなくて、面白い作品がライトノベルにもいっぱいあったよ！ ただそれだけのことだと思います。 ライトノベルと小説、違いは確かにあります。 が、刺さるものは刺さるし、刺さらないものは刺さらない。それは変わりません。 これからも自分の心に響く作品に出会える日々を楽しみにして生きようと思いました。

ライトノベルと小説の違い

最近POGの集計用サイトを自作しました。 <a href="https://ouchi-pog.vercel.app/" target="_blank" rel="noopener noreferrer">https://ouchi-pog.vercel.app/</a> 特に意識してなかったのですが、ふと思い立ってLighthouseのスコアを計算してみたところ、 なんと満点が記録できました。 （PWAは改善点ありですが） <img src="https://images.microcms-assets.io/assets/662af00d6f2f4f2eb4714bdc9fcdb3d1/610d4ca21ccc4495a4a0e9ddc3524ab7/lighthouse.png" alt=""> 全ページSSGで特に動きのある処理はないのでまあ当然といえば当然なのですが、 100 が揃うと気持ちいいですね。Next.jsの恩恵がでかいです。 このブログのスコアは壊滅的なので、早く改善したい。。

自作サイトのLighthouseスコアが満点になりました

Lighthouseのスコアが満点に

映画「ハケンアニメ！」を見てきました。 <a href="https://haken-anime.jp/" target="_blank" rel="noopener noreferrer">https://haken-anime.jp/</a> <h2 id="h238ede8e0c">あらすじ</h2> アニメ制作をテーマにしたお仕事ものです。 原作は同名の小説になります。 アニメは3ヶ月を1シーズンとして放送されることが通例で、 1年で4シーズン、数多くのアニメが放送されています。 シーズンの中でも特に「いい」アニメを今期の覇権アニメ、という言い方をするのですが、 その「覇権」をとるべくアニメ制作に命をかけるクリエイターたちのお話になります。 同シーズンに放送される2つのアニメ「運命戦線リデルライト」「サウンドバック　奏の石」、 それぞれの製作陣の奮闘を通じて、アニメって最高だなと思わせてくれる作品でした。 <h2 id="h8d78e14043">感想</h2> めちゃくちゃよかった。 アニメパートが仕上がりすぎていて感動しました。 映画が公開されたのが5月下旬だったのですが、実はその時まで作品を知らなくて。 気になって調べてみると、同名の小説が原作だというじゃありませんか。 映画はまあそのうち見るとして、読書好きとしては原作を読まずに映画を見るわけにはいかない。 そんな使命感に駆られて小説を読みまして、これがまあ面白かったんです。 刊行されたのが2012年で、アニメを取り巻く環境は少し今と異なる描写でしたが、 アニメ好きにはとても刺さる作品でした。 アニメ制作のお話なので作中で架空のアニメが登場するんですが、 これがすごく良かったんです。 文字しか情報がない小説でも、音・映像・声優さんの演技がとてもリアルに伝わってきて衝撃を受けました。 「映画はそのうちいくなんてレベルじゃない、今すぐ見なければ！」と思って読み終わってすぐに映画館に走ったわけです。 <h3 id="he6c6176192">映画の感想</h3> 上でも書いた通り、アニメパートのクオリティがやばいです。 登場する架空の2作品、どちらも劇場版アニメのような仕上がりで（まあ映画の中だからそうなんですが）、 1つの映画の中に劇場版アニメが2つ含まれているってやばくないですか？ それこそ実際に放送されていたら「覇権」を間違いなくとれるレベルで、 劇中アニメとして終わらせてしまうのがもったいない、、。 なにより、小説を読んでいる時に自分の頭の中に思い描いていた映像が、 そのままスクリーンに表現されているようでとてつもなく感動しました。 作り手のアニメが好きという気持ちが伝わってきたのもよかったです。 え、アニメパート以外の話は？ うん、まあそこは小説の実写化ということで。。 小説そのままだと尺が絶対にたりないのは明白なので、 アニメパートを殺さないように頑張って脚色されていた点はよかったです。

ハケンアニメ！

前回更新からかなり間が開きましたが、仕事が落ち着いてきたのでまたぼちぼち更新していこうと思います。<h2 id="h0a73125737">更新しなかった理由</h2><ul><li>仕事が忙しい</li><li>ブログの更新が面倒くさい</li><li>microCMSのプランが変わった</li></ul> ...自作しておいて面倒くさいってなんやねん、とツッコミたくなるところですが、 自分の性格への理解が足りていませんでした。 巷で見かけるおしゃれなブログに憧れて装飾性を頑張った結果、 投稿するコストが高くなって億劫になっていたのでした。 特にサムネイル画像。 これはいらなかった！ 全部Sketchで自作していたのですが、文章よりも時間がかかって本末転倒でした。 書きたいのは文章なので、「文章さえかけばいい」状態にして執筆環境を整えます。 3つ目の料金プランについて。 このブログの記事管理で使っているmicroCMSの料金プランが変更になりました。 <a href="https://microcms.co.jp/news/20211129-01/" target="_blank" rel="noopener noreferrer">料金プラン改訂のお知らせ</a> 2021/12/16 現在の料金プラン <img src="https://images.microcms-assets.io/assets/662af00d6f2f4f2eb4714bdc9fcdb3d1/d3a1cbf9b36f499a83de43c7e326169a/image.png" alt=""> 2022/1/17 からの料金プラン <img src="https://images.microcms-assets.io/assets/662af00d6f2f4f2eb4714bdc9fcdb3d1/862acc23c0b54cb9bf64cd2b811b15d7/image.png" alt=""> 無償プランである「Hobby」を使っていましたが、 使用できる機能が大幅に制限されました。 APIが3本までになったのは痛いです。 気に入っているサービスなのでお金を払うことに抵抗はあまりないのですが、 趣味に月5000円は高すぎる。いいスペックのサーバーレンタルできるやん。 使用している機能が動かなくなるので対応しないとなーと思っていて3ヶ月ほどが過ぎてしまいましたが、 これを機にいらない機能をそぎ落としていきたいと思います。

ブログをリファクタリングします（予告）

<h1 id="h7d00ebde93">炎の十番勝負 2021 秋</h1> 毎年おなじみ、グリーンチャンネルの企画です。 今回も参加するので、メモがてら記録しておきます。 <h2 id="h2b08314bc7">スプリンターズステークス</h2>ファストフォース <h2 id="h3c70de0ca4">秋華賞</h2>ソダシ <h2 id="h2d91da2895">菊花賞</h2>オーソクレース <h2 id="had5c06a3cc">天皇賞（秋）</h2>エフフォーリア <h2 id="h97d2a9d156">エリザベス女王杯</h2>ウインマリリン <h2 id="he8dd2e6802">マイルチャンピオンシップ</h2>カテドラル <h2 id="hb6b6bae637">ジャパンカップ</h2>カレンブーケドール <h2 id="h0a947b9d17">チャンピオンズＣ</h2>エアスピネル <h2 id="h7a4ec008c2">阪神ジュベナイルフィリーズ</h2>フォラブリューテ <h2 id="h4c7811067f">朝日杯フューチュリティＳ</h2>プルパレイ <h2 id="h0eaa6defe0">有馬記念</h2>クロノジェネシス <h2 id="h0228e86055">ホープフルステークス</h2>アートハウス <h2 id="ha214098e44">まとめ</h2>秋華賞は別として、自信があるのはマイルCSです。 前走の京成杯AHを勝ち切ったあたりハーツクライの覚醒期が来たのではと踏んでいます。 ホープフルステークスのアートハウスはまだデビューしてなくて、 クラブ馬でもなければノーザン馬でもないダークホースです。 母のパールコードが好きだったのですが、牧場（三嶋牧場）の評判はかなり高いようで、 来年のクラシック含めかなり楽しみにしています。 毎回指名馬が出走しないパターンが多いので、今回はフル出走してほしい、、。

2021秋G1予想（GC企画・炎の十番勝負）

<h1 id="h88a63fbb6a">紫苑ステークス</h1><ul><li>中山芝2000m</li><li>G3</li><li>秋華賞トライアル</li></ul>重賞に格上げされてから、本番との関連性がグッと高くなったレースですね。 過去3年の勝ち馬は<ul><li>マルターズディオサ</li><li>パッシングスルー</li><li>ノームコア</li></ul>2、3着馬も含め、前々で競馬した馬での決着となっています。 開幕週での開催になるので、今年も位置どりは馬券上意識したいところです。

## 予想

race ◎ 15 スライリー

race ○ 8 メイサウザンアワー

race ▲ 13 ハギノピリナ

race △ 10 エイシンチラー

race △ 16 クィーンスイープ

race △ 17 ホウオウラスカーズ

race △ 18 プレミアエンブレム

:::raceplan
逃げたい馬はアビッグチア・プレミアエンブレムあたりでしょう。  
距離延長にはなりますが、逃げで戦法を確立しているアビッグチアはハナにこだわると思います。  
それを見る形で進めそうなのが、スライリー・メイサウザンアワーでここがポジション的に有利にと言えるでしょう。  
エイシンチラーは前走が差し競馬でしたが、本来は先行策もできる馬でスタート決まれば好位で運ぶと予想。  
スライリーはオークスでも強気な競馬をしていましたし、ハギノピリナも3角あたりから動いてくることを考えると、  
単純な前残りにはならなさそうです。  
後ろから差してきそうなクィーンスイープ・ホウオウラスカーズあたりも、流れ次第では食い込んでくると思います。
:::

## 買い目
:::betting
3連複  
15,8 - 15,13,8,18 - 15,13,8,18,10,16,17
:::


【競馬予想】紫苑ステークス2021

<h1 id="h276d1ab152">月姫 - A piece of blue glass moon -</h1><a href="http://typemoon.com/products/tsukihime/" target="_blank" rel="noopener noreferrer">http://typemoon.com/products/tsukihime/</a> Fateシリーズ等でおなじみのTYPE-MOONが同人サークル時代に制作したビジュアルノベル。 いわゆるノベルゲーはやってこなかったのと、「月姫」という名前も聞いたことはなかったのですが、 Fateのアニメは大好きなのでプレイしてみました。

:::note alert
ネタバレ含みます
:::

**めっっっっちゃおもしろかった！！**
  
この一言が全てです。  
絵・音楽・ストーリー・キャラクター、どれもが最高でした。  
ここまで自分にストライクな作品に出会えて、とても嬉しいです。  

<h2 id="h866245cc01">ストーリー</h2>公式HPなどの情報を一切見ずに購入、プレイしたので、 どんなストーリーなのか全く知らないまま進めていました。 序盤の各キャラの自己紹介パートが結構長かったのですが、不穏な雰囲気を醸しつつも日常的な話だったので、 アルクェイド登場のシーンは正直ぶったまげました。 17分割のシーン、イラストのリアルすぎて声が漏れましたね。あれは心構えしてないとビビる。 ストーリーを進めていると選択肢が出てくるのですが、これがまた絶妙なんですよね。 選択肢によっては即バッドエンドになるものが用意されていて、選ぶ段階で妙な緊張感があります。 初回は「自分だったら...」と考えて選択していましたが、外した時のショックといったら。 バッドエンドにもちゃんとシナリオ・イラストが用意されているので、途中までは正解ルートだと思っちゃうんですよ...。 なぜバッドエンドになったのか理解できないケースも中にはあり、 「教えてシエル先生！」という振り返りヒントコーナーが無いと詰んでいたかもしれません（笑）。 今作は、「アルクェイド」「シエル」の2ルートしか収録されていません。 しかし、それでもボリュームが足りないなんてことはなかったです。 というのも、2ヒロインのシナリオが全く違ったからなんですよね。 てっきり『同じ時系列の物語を違う側面から体験する』類のものだと思っていたんですが、 途中からシナリオが全然別物になって、終始ハラハラしたストーリーでした。 <h2 id="hf5afc231fb">ヒロイン</h2>最初はアルクェイドルートしか選べないこともあって、半ば必然的にアルクェイドに惹かれていきます。 喜怒哀楽がハッキリしていて、表情がコロコロ変わるので見ているだけでも楽しいかったですね。 主人公の志貴に感情をストレートにぶつけてくるシーンが多く、プレイ中に何度悶絶したことでしょうか。 可愛くて・カッコよくて、ん？もうアルクェイド以外のルートなくても問題なくない？という気持ちにされられました。 アルクェイドルートを終えて放心状態でしたが、アルバムを埋めるために渋々「シエル（先輩）ルート」をプレイしました。 それくらい、最初はあまり惹かれていなかったのですが、 シエルルートのOPが流れる頃には「先輩好き！」という感情が芽生えていました。&nbsp;&nbsp; 癒し系先輩キャラというポジションだと思っていたのですが、 シエル先輩の信条やこれまでの経緯を知っていくにつれ、アルクェイドと肩を並べる正統派ヒロインであることに気づきます。 主人公・志貴と対決するシーンが物語の終盤で出てきますが、あれは泣きます。。。 <h2 id="h9785e21bf0">その他キャラ</h2>全員について感想書くとキリがないので、秋葉と志貴について。 「志貴、お前ちゃんと秋葉さまの言うこと聞け！」 作中で何回こう思ったことでしょうか。 名家の当主である妹の秋葉さま、自堕落な兄に対して厳しく門限やルールを設定してくるのですが、 志貴がそれを全然守らないんですよ。 最初は暗くなる前に帰宅、とか言われて可哀想だなと思ったりしたんですが、 兄のことを心配してくれているのが画面越しの自分にも伝わってきて、 秋葉が不憫になってしまうこともしばしば。 体調不良が続いてるから安静に、と言われてもアルクェイドと夜な夜な歩き回ってるし。。 そんなこんなでアルクェイドルートをプレイ中「次は秋葉ルートやるぞ！」と思っていたら、 今回は未収録としって打ちひしがれたのはいい思い出です。 あと、アルクェイドは志貴にストレートに思いをぶつけてくるのに対し、 志貴は心の中で気持ちを反芻するだけのシーンが多いんですよね。 と思ったらシエル先輩に対してはグイグイ攻めているので、掴めないけど魅力的なキャラだなあと思いました。 そして、声優さんがキャラにマッチしててすごかったです。全員。 <h2 id="h7ed4469e61">イラスト・背景</h2>PVでもわかる通り、背景とキャラが素晴らしい仕上がりなのは、言うまでもありません。 衝撃だったのは、キャラの立ち絵が1ページごとに、一言ごとに切り替わることです。 「文章を追うのがメインで、説明程度にキャラと背景がある」というのがノベルゲームの勝手な印象だったのですが、 このゲーム、イラストがパラパラと切り替わるんですよね。 これは制作時間長くなるわ、、と思うと同時に、クオリティの高さに感動しました。 <h2 id="h4165545bd4">音楽・映像</h2>OPの映像はufotable、主題歌・挿入歌はReonaさんということで、最高の布陣ですね。 公式Youtubeで公開されていて、何度も手軽に見返すことができます（ゲーム内からでも可能です）。<ul><li><a href="https://www.youtube.com/watch?v=9B282GYZqCg" target="_blank" rel="noopener noreferrer">https://www.youtube.com/watch?v=9B282GYZqCg</a></li><li><a href="https://www.youtube.com/watch?v=7bu39dMD5MA" target="_blank" rel="noopener noreferrer">https://www.youtube.com/watch?v=7bu39dMD5MA</a></li></ul> 映像だけでもちろん最高なのですが、 文章とイラストだけでは補完しきれなかった描写が表現されており、プレイ後に見ると感慨深いものがあります。 アルクェイドの「爪」やヴローヴの「炎の手」、実際にみると迫力がありますし、 シエルルートOPでの先輩の戦闘シーン、最高にかっこいいです。 <h2 id="h1afe451c43">さいごに</h2> プレイし終えた今、「早く他ルートをプレイしたい」という感情が1週間ほど自分を支配しています。 全エンド回収すると次回作の予告編が見れるのですが、これがヤバいんですよ...（語彙力）。 さて、月姫に登場するキャラクターが登場する2D格闘ゲーム「MELTY BLOOD」が9月末に発売されます。 こちらもリメイクらしいのですが、もちろん買います！