Github APIからIssueとコメントを取得→はてなブログに投稿するPythonスクリプト書いた

こないだから書いてるやつ、とりあえず形になったので晒してみる。 github.com

コード全体像

# coding:utf-8
import os
from os.path import join, dirname
from dotenv import load_dotenv
import requests
from requests.auth import HTTPBasicAuth
import json
import datetime

load_dotenv(verbose=True)

dotenv_path = join(dirname(__file__), '.env')
load_dotenv(dotenv_path)

GITHUB_ID = os.environ.get("GITHUB_ID")
REPOSITORY_NAME = os.environ.get("REPOSITORY_NAME")
HATENA_ID = os.environ.get("HATENA_ID")
BLOG_URL = os.environ.get("BLOG_URL")
HATENA_PASSWORD = os.environ.get("HATENA_PASSWORD")

def fetchGithub():
    dt = datetime.datetime.now() + datetime.timedelta(hours=9)
    issues_url = "https://api.github.com/repos/{}/{}/issues?direction=asc&state=all&since={}T00:00:0Z"
    issues = issues_url.format(GITHUB_ID, REPOSITORY_NAME, dt.date())

    response = requests.get(issues)
    res = response.json()

    blog_title = "Issueなし"
    blog_body = "無為に過ごした1日"

    if len(res) != 0:
        blog_title = res[0]['title']
        blog_body = ""

        for r in res:
            headline = "### " + r['title'] + "\n"
            blog_body += headline
            blog_body += r['body'] + "\n\n"

            number = str(r['number'])
            comments_url = "https://api.github.com/repos/{}/{}/issues/{}/comments"
            response = requests.get(comments_url.format(GITHUB_ID, REPOSITORY_NAME, number))

            comments = response.json()
            for c in comments:
                blog_body += c['body'] + "\n\n"

    postHatena(blog_title, blog_body)

def postHatena(title, body):
    date = datetime.datetime.now()
    xml_template = """<?xml version="1.0" encoding="utf-8"?>
  <entry xmlns="http://www.w3.org/2005/Atom"
      xmlns:app="http://www.w3.org/2007/app">
  <title>{}</title>
  <author><name>virtual-surfer</name></author>
  <content type="text/x-markdown">{}
  </content>
  <updated>{}</updated>
  <category term="自動投稿" />
  <app:control>
      <app:draft>yes</app:draft>
  </app:control>
  </entry>
  """.format(title, body, date)

    headers = { "Content-type": "application/xml" }

    hatena_url = "https://blog.hatena.ne.jp/{}/{}/atom/entry"
    request = requests.post(
        hatena_url.format(HATENA_ID, BLOG_URL), timeout=10, headers=headers, data=xml_template.encode("utf-8"),
        auth=HTTPBasicAuth(HATENA_ID, HATENA_PASSWORD)
    )

    print(request)

def main():
    fetchGithub()

if __name__ == "__main__":
    main()

APIを叩くために必要な値は.envから読み込んで定数に入れておいた。

Pythonで.envを読み込むために以下のライブラリを使用。 https://pypi.org/project/python-dotenv/

load_dotenv(verbose=True)

dotenv_path = join(dirname(__file__), '.env')
load_dotenv(dotenv_path)

GITHUB_ID = os.environ.get("GITHUB_ID")
REPOSITORY_NAME = os.environ.get("REPOSITORY_NAME")
HATENA_ID = os.environ.get("HATENA_ID")
BLOG_URL = os.environ.get("BLOG_URL")
HATENA_PASSWORD = os.environ.get("HATENA_PASSWORD")

• GITHUB_ID: Githubのアカウント名
• REPOSITORY_NAME: Issue等を取ってくる対象のリポジトリ名
• HATENA_ID: はてなID
• BLOG_URL: 投稿先のブログのドメイン
• HATENA_PASSWORD: はてなブログAtomPubのAPIキー

GithubのAPIからリポジトリごとのIssueを取得

https://docs.github.com/en/rest/reference/issues#list-repository-issues 公式ドキュメントを参考に。

dt = datetime.datetime.now() + datetime.timedelta(hours=9)
issues_url = "https://api.github.com/repos/{}/{}/issues?direction=asc&state=all&since={}T00:00:0Z"
issues = issues_url.format(GITHUB_ID, REPOSITORY_NAME, dt.date())

response = requests.get(issues)
res = response.json()

URLのパラメータは、

• direction: Issueの番号のソート順。先に起こしたものから順番に取りたかったのでasc。
• state: Issueの状態（オープンかクローズか）。今回は状態に関係なく取得したかったのでall。
• since: どの日時以降のIssueを持ってくるか。

sinceは「スクリプトを実行した時点より24時間以内のもの」を取ってこれるよう要改良。 Github上の投稿時間とかちゃんと調べられていない。

Issueのコメントを取得

https://docs.github.com/en/rest/reference/issues#list-issue-comments

ひとつでも対象のIssueがあれば、そのIssueのタイトルをブログのタイトルに設定。

### Issueのタイトル
コメント

コメント

最終的に本文が↑の形になるように、APIからコメントを取得。

if len(res) != 0:
    blog_title = res[0]['title']
    blog_body = ""

    for r in res:
        headline = "### " + r['title'] + "\n"
        blog_body += headline
        blog_body += r['body'] + "\n\n"

        number = str(r['number'])
        comments_url = "https://api.github.com/repos/{}/{}/issues/{}/comments"
        response = requests.get(comments_url.format(GITHUB_ID, REPOSITORY_NAME, number))

        comments = response.json()
        for c in comments:
            blog_body += c['body'] + "\n\n"

はてなブログに下書きとして投稿

http://developer.hatena.ne.jp/ja/documents/blog/apis/atom

はてなブログへの投稿はXML文書を送る必要があるとのことだったが、XML形式の文字列を送ってやるだけで全然行けた。

def postHatena(title, body):
    date = datetime.datetime.now()
    xml_template = """<?xml version="1.0" encoding="utf-8"?>
  <entry xmlns="http://www.w3.org/2005/Atom"
      xmlns:app="http://www.w3.org/2007/app">
  <title>{}</title>
  <author><name>virtual-surfer</name></author>
  <content type="text/x-markdown">{}
  </content>
  <updated>{}</updated>
  <category term="自動投稿" />
  <app:control>
      <app:draft>yes</app:draft>
  </app:control>
  </entry>
  """.format(title, body, date)

    headers = { "Content-type": "application/xml" }

    hatena_url = "https://blog.hatena.ne.jp/{}/{}/atom/entry"
    request = requests.post(
        hatena_url.format(HATENA_ID, BLOG_URL), timeout=10, headers=headers, data=xml_template.encode("utf-8"),
        auth=HTTPBasicAuth(HATENA_ID, HATENA_PASSWORD)
    )

レスポンスが返ってこなかったときのエラー処理とかは追々書いていく。

Issueとブログを連携させようとした意図がわかりにくかった

ので、改めて狙いを整理したい。

自分は元々長い文章の構成をまとめるのが苦手。 ブログ等を書こうとしても「今日は何をネタにするのか」「そのためにどんな情報が必要か」などを考えているうちにどんどん考えが膨らんでしまい、最終的に収集がつかなくなる→書くこと自体が億劫になる、ってサイクルを繰り返していた。

その反面、短い文章を端的にまとめるのは苦ではないと思っている。 であれば、考えるべきテーマ→それに対しての答えを端的に連ねていくGithubのIssueのような形なら、全体の構成に頭を悩ませずに済むのではないかと仮説を立てた。

1. その日起こしたIssueとそのコメントをAPIから機械的に拾う
2. はてなブログに下書きとして投稿させる
3. それを元に記事を編集する

といった流れを作って、長文を書くのに少しずつ慣れていくのが目的。

Issueに上げるテーマ

自分が問題に思っていることや関心事で、自身や他人のプライバシーに関わらないもの（ネットで公開しても差し支えないもの）ほぼ全部。

仕事や個人開発で詰まったことや、プライベートでやりたいけどできていないことなどをガンガン取り上げていって、それに関連した考えたこと、調べたことを端的にメモに残していく。

プログラミングに関して言えば、GithubでもはてなでもMarkdownでコードが書けるので、量が溜まればスニペット集としての役割を果たしてくれることも期待。

print('Hello World')

実行環境

Github APIからIssueとそれに紐づくコメントを取得→はてなブログのAPIに下書きとしてPOSTするPythonスクリプトは昨日(2020/09/22)の時点で作成済み。

これをAWSにLambdaとしてアップ→1日1回定期的に実行させるのが目標だが、ローカルではちゃんと動作してくれるものの、本番にアップしたものがうまく動作してくれない。

なので当面はローカルで実行しつつ、動作しない原因を調べて修正するのが目標。別でIssueを立てているので、修正が完了したらCloseする。

ブログの位置づけ

単純に「日々の記録」として。その日によって内容がころころ変わる「公開の雑記メモ・ネタ帳」みたいな感覚。

何か特定のテーマを取り上げてまとめるのは完全に別枠でやる。 特別な日（旅行とかの記録）やエモ寄りの記事ならnote。技術的な記事ならQiitaか、最近話題のZennか。

もしそれらの媒体に記事を執筆したとしたら、その旨とリンクを記録するアンテナとしての役割も。

そもそも、ブログを書く目的

有益な情報を人と共有する側面もあるが、

自己理解をしやすくするため

書いたものを後で振り返った時に、執筆時の状況とその時とを比べて自分がどう変化したか、逆に何が変わっていないのか等を見て自分という人間をより正確に把握したい。

それを見て他の人に自身の人となりを知ってもらうため

コロナ渦の影響で人と対面する機会が激減し、新しく人と出会うチャンスも少なくなった。 そういう中でネット上だけでも自分という人間を認知してもらって、何か新しいことができるきっかけを作りたい。

ブログ記事を半自動的に生成できないかいろいろ実験してみた

この記事は https://github.com/kamonohashiK/blog_automationに上げたIssueをプログラムで拾い上げれば、それをそのままブログの下書きに使えるのではないかというアイデアのもと、試験的に書いてみたものです。

まだまだ実用レベルには至っていないとは思うものの、過去の思考の過程を追っかけるにはいいんじゃないかと思ってあえて公開してみます。

GithubのIssueからブログ記事を自動投稿できるようにする

• 自分の考えを表明するために文章を書かなきゃいけないなあと思った
• ただまとまった量の文章を書こうとすると上手くまとめきれないことが多い

• 毎日ネタをひねり出すのもつらい

• Twitterとか断片的に情報出すのは無理なくできている

• だったらいろんなサービスに断片的に書いていることを拾ってきて、それを一箇所にまとめてしまえばいいのではないか？

• アウトプットしたいと思った理由：自分の人となりを知ってもらうこと

• 何をしたらそれが伝わるか？（仮説）：問題意識とその解決方法を見せる

• その人が何をしたい（したくない）と思っているのか、そのために何をするのかを聞くのがいいんじゃないのか

• GithubのIssueってそういう機能だよね、と思った

• まずでかい問題があって、それを解決するための過程などを追記していく

• だったらこれをそのままブログにすればよくね？と思った

• ブログネタ（平たく言えば自分の問題意識）用のリポジトリを作って可視化

• APIを叩いてその日起こしたIssueやコメントを機械的に拾って
• ある程度編集したら記事として公開してしまう

• どうせなら投稿もはてなのAPIとかで自動化してしまいたい

• GithubもはてなもAPIの存在は知ってるが、思った機能が使えるかどうかは知らない

• まずはそれを調べるところから始めよう

GithubのAPIでできることを調べる

1 を実現するために必要な情報が取れるのかを調べる

・指定したリポジトリのIssueとコメントの一覧が取れるか ・日付で絞り込みができたらなおGood

Issueごとのコメントはここで取れる

https://docs.github.com/en/rest/reference/issues#list-issue-comments

リポジトリごとのIssueのリスト https://docs.github.com/en/rest/reference/issues#list-repository-issues

まずIssueの一覧を取ってきてそのIDからコメントの一覧を取得するイメージかな？

楽勝で取れるっぽいので簡単なコード書いて試してみる

はてなブログのAPIについて調べる

Github APIから取得したIssueの文章をはてなブログに投稿できるようにする

https://kamonohashik.hateblo.jp/

XMLをPOSTしてやると新規投稿ができるらしい

http://developer.hatena.ne.jp/ja/documents/blog/apis/atom

ここからログインしてread_public, write_publicを有効にする

https://www.hatena.ne.jp/kamonohashiy/config/auth/develop

適当極まりないがとりあえずPythonで要件を満たすコードが書けた。

パスワードとかもハードコーティングしちゃってるので、まだ公開はしない。 AWSにSAMで上げて自動投稿できるようにした段階でプッシュする。

cronで自動実行されない

SAMからローカルで実行したときは正常に動くのだが、cronで指定したはずの時間に自動実行されない。

何かが間違っているのか、要調査

Issueを起こしたときの最初のコメントが記事に反映されていない

タイトルの通り

Issueを取ってきたときのレスポンスのbodyにコメントが含まれているので、それを表示するよう修正。

半年ぶりのブログ更新

半年くらい更新サボってたけど、今日なぜか急に書きたくなったので、空白期間にあったことをダイジェストでまとめてみた。

AWSのSolution Architect(Associate)認定試験に合格した

社長に(たぶんパートナー認定の関係で)「必須だから」と強めに言われてビビりながら受験した結果なんとか合格できた。

AWSの認定自体は都合3回(初回はなぜかデベロッパー、2回目からはソリューションアーキテクト)受けてて今回やっとという感じ。

1年前の初回受験の時は最寄りの試験会場が神戸とかにしかなくて、深夜か早朝かよくわからん時間に会社の先輩に車出してもらって受けに行った(そして全員不合格になって帰ってきた)のだが、1年の間に松山でも受験ができるようになったので、移動に伴う負担がなくなったのはかなりデカいと思う。

ちなみに対策はと言うとUdemyで評判のよかった動画講座(試験の結構前、ディスカウントで安くなってた時に購入)を流し見→サービスごとの全体像を把握、ってのをほぼ一夜漬けでやったくらい。

で終わってしまうと身もふたもない感じなので、もう少し合格者っぽいコメントを出すとしたら、

• コストと可用性、耐久性はトレードオフ。これらの観点から横に並べて整理しよう
• サービスの概要知ってれば即答できる問題も少なくないので、それは絶対取りこぼさないように

みたいな感じだろうか。

このへんは記事を改めて詳しく書いてみてもいいかもしれない(どうせ書かないフラグ)

Google系技術が面白いなあと思い始めた

AWS系資格取った、と書いたすぐ後にこれである。

春頃にFirebaseの勉強会に行って、その時は面白いなーと思いつつもなかなか手を出せていなかったいなかったんだけど、最近になって練習で組んでみたらFirestoreだけでもめちゃくちゃ面白くなって(他の機能は全然使えてないんだけど)。

そこにGoを勉強する機会もあったので「バックエンドの大部分はFirebaseでサクッと組んで、それで足りない部分をCloud FunctionsをGoで補う」アーキテクチャで組んでみたいな、とか思うようになったり。

そうなったらフロントもAngularで組むようにして、Google謹製技術のみで一本アプリ組んでみようかな、という気になったので、当面はこれらを重点的に勉強していくつもり。

しまの時刻表のUIを刷新した

このブログで一時期狂ったように進捗報告していたしまの時刻表だが、新機能を追加したくなって、その前段階として画面のレイアウトをがっつり変えてみた。

で、久しぶりにソースを触ろうとしてみたら、CSSフレームワークで使っていたVuetifyの仕様がガッツリ変わってて、バージョンが古いままだとマトモに動作しない箇所が複数出てきたので、UI部分は新規にリポジトリ作ってガッツリ書き直してやった。疲れた。

疲れたので当初の目的である新機能(ユーザーが画像や島ごとの感想を投稿できる、SNS的な感じにしたい)の実装は全然追いついてないのだけど、今の時点でバグ見つけてたりコードの中身ぐっちゃぐちゃになってたりするので当面はバグつぶしとリファクタリングに専念することになりそう。

ただ前々からの課題である(肝心の)時刻表データの収集・反映方法も確立できてなかったり、個人開発で他にもやりたいネタがあったりして、それぞれに優先順位がつけられないのが非常に悩ましい現状。

ただ仕事の合間を縫っての開発って残業がさほどない今の会社にいてすら手一杯な面があるので、普段の休みは地道にやりたい技術のドキュメント読み込みと写経に専念→大型連休時にガッツリ手入れ、くらいのペースを作るのが一番いいんじゃないかと思ったりもするし。

公私ともにいろいろ効率化しないと追っつかないな、と思う今日この頃。

やっぱりモンキーが欲しくなった

以前の記事でだいぶ迷ってると書いてた次のバイク候補、モンキー125でほぼ一本に決まってきた。

金額的に多少高いとか、積載性が低いとかはつらいとこだけど、

• 何回見てもデザインとまたがった時のフィーリングが素敵
• 中型を手放した後もMT車に乗り続けていたい
• 実用性よりも遊び心を取る、ってのが自分的にしっくり来る

等々が決め手かなと。

中型のローン完済＆自賠責が切れる来年2月くらいのタイミングで乗り換えようという腹づもりでいる。

33歳になった

割とどうでもいい。

PythonでCSVのデータをjson形式で出力するスクリプト書いた

最近別のサービス案の構想したり腑抜けてたりして全然進んでなかったしまの時刻表のデータを仕込む作業を再開。

以前の記事の段階で座標データを取得→明らかにおかしかった部分を手動で修正したので、これを元に初期状態の時に表示するマーカーのデータを入れていく。

マーカーのデータは下のような形式のjsonを静的ファイルとして読み込ませているので、要はこのindex_itemsって配列の中にCSVのデータを流し込んでやればOK。

{
  "index_items": [
    {
      //緯度・経度
      "position": {
        "lat": 45.392277,
        "lng": 141.015036
      },
      "title": "礼文島",
      "locale": "礼文町",
      "top_img": null, //ピンをクリックしたときに表示される画像
      "slide_items": null, //画像がある場合、配列でパスを指定
      "timetable": false //時刻表の有無
    },
    //こんな感じのデータが延々並ぶ

てなわけでそれをやったコード。

#coding:utf-8
import csv
import json

items = {
  'index_items': []
}

with open('zahyo.csv', 'r') as f:
  reader = csv.reader(f)
  header = next(reader)

  for row in reader:
    line = ({"position": {"lat": round(float(row[2]), 6), "lng": round(float(row[3]), 6)},"title": row[0],"locale": row[1],"top_img": None,"slide_items": None,"timetable": False})
    items['index_items'].append(line)

f = open('output.json', 'w')
json.dump(items, f, indent=2, ensure_ascii=False)

特筆するようなところは特になし。json.dump便利。

で、ローカルでちゃんと表示されるか試してみたら結構衝撃的な絵になった。

この間作った有人離島のリストから位置をGoogle Mapで可視化してみた結果

ヤバすぎひん？特に西日本 pic.twitter.com/kU9KFXMaFG

— かものはしくれ (@kamonohashi_kre) 2019年5月16日

馴染みの深い瀬戸内海だけど、まだこの中の半分にも行けてないのかと思うとちょっとロマンを感じてしまう不思議。

この後は「各島とそこへ行く船が出る本土側の港」の座標データ、さらにはその船の膨大な量の時刻表データが欲しいんだけど、さてどうしたもんかな。

「うんこプログラミング道場」に可能性があるか、実際書いて確かめてみた

日中あまりに能率が上がらなくて↓こんなくだらないもの書いて遊んでいたんだけど。

あまりに元気が出ないのでクソコードを書いた pic.twitter.com/7YFn0x5kR5

— かものはしくれ (@kamonohashi_kre) 2019年5月15日

一時期「○んこ漢字ドリル」が流行ったみたいに一見難しそうな題材、それこそプログラミングにうんこを交えた教材ができたら売れるんじゃね？と冗談交じりに考えたことがあって。

(たとえばfor文を覚えたらいちいちキーボード打たなくてもターミナルを一瞬でうんこまみれにできるよ！みたいなアプローチ)

で、小学校高学年くらいの子を対象に実際に書いてみたらどうなるんだ？と思ってやってみたら執筆中はめちゃくちゃハイになったのに見直してみたらクソ以外の何物にもならなかったので、供養のために載せてみる。

内容的にはPythonのごくごく最初に勉強することなので、頑張って読む価値は特にないです。

Hello, Unko!

プログラミングを始めるときには、ふつう'Hello,World!'という文字を画面に出すところから始めます。

ですが、クールなみなさんはもっとクールな言葉から始めるべきです。

print('Hello, 💩!')

printは()の中のものを出力(画面で見えるようにする)する命令です。

Hello,💩!の前後についている'記号(シングルクォーテーション)は「最初の'から最後の'の間のものを文字としてあつかう」という意味です。

なのでこのプログラムは「Hello,💩!という文字を画面に出して！」という内容になります。

プログラミングを覚えると、うんこを出すより簡単に文字が出せるんですね。

いろいろな型(かた)

プログラムでは文字を出す以外にも、数字を使ったり計算をしたりすることが出来ます。

たとえば次はこのようなプログラムを書いてみましょう。

print(2 + 3)

実行結果に「5」と表示されましたか？

また、プログラムでは、足し算以外にもさまざまな計算をすることができます。

print(5 - 3) # 2
print(5 * 3) # 15 *はかけ算の×と同じ
print(6 / 3) # 2 /はわり算の÷と同じ
print(5 % 2) # 1 5÷2のあまり

ところで、最初に書いた'Hello,💩!'のときとちがって、"'"の記号はどこにも使っていないことに気が付きましたか？

"'"は中のものを「文字として」(正確には「文字列」として)扱うためのものでしたが、数字や計算をするときには不要になるのです。

ためしに、計算で使っていたプログラムを少し書きかえてみましょう。

print('2 + 3')

こんどは「5」ではなく「2 + 3」がそのまま画面に表示されましたね。これは「2 + 3」を計算式ではなく、文字列として扱っているからです。

「型」がちがうとどうなるの？

型がちがうもの同士をあつかうときには注意が必要です。たとえば、下のように文字列の'2'と数字の3をそのまま足し算しようとするとどうなるでしょうか？

print('2' + 3)

エラーになってしまいました。では今度は、どちらも文字列にして足してやるとどうなるでしょうか?

print('2' + '3')

なんと、23という結果になりました。Pythonでは、文字列同士を足してやると前の文字列のおしりに後ろの文字列がくっついて表示されるのです。

さて、計算式ばかりを見てきてそろそろ眠くなってきました。ではここはためしに、文字列と数字を掛け算したらどうなるかを見てみましょう。

print('💩' * 10)

見事に💩が10個表示されました！Pythonには文字列と数字とをかけると、文字列がかけた数のぶん連続して表示される機能があるのです。

ここからが本番です。

これさえ覚えればいつでも好きなときに画面を💩まみれにすることができるようになりました。

次回からはうんこをより便利に扱うための方法を、ふんだんにあつかっていきましょう。

..続くんかい。

EnjoyHONDAに遊びに行ったら自分の中で「さるかぶ合戦」が勃発した

タイトル通り、ホンダのイベントが自宅近くのアイテムえひめであったので遊びに行ってきた。

www.honda.co.jp

超ざっくり言うと「ホンダのクルマとバイクをいっぱい持ってきたよ！自由に乗ったり触ったりできるよ！お祭りみたいで楽しいよ！」って類のやつ。

試乗会があったりデモンストレーションがあったり、写真撮影が出来るブースやキッズ向けの各種体験コーナーがあったりしたのだが、自分の場合そのへんは特に触れず(見れず)、ただただ展示してるバイク眺めてるだけでも結構楽しめたのでその感想を。

ホンダの現行車種(多分ほぼ全部)にまたがり放題

自分はクルマにはあまり興味がないのでほぼバイクのコーナーを見ていたんだけど、それだけなのになぜか異様に楽しかった。

原付自由にまたがれるコーナーあったので試してみる

C125は短足ワイだと片足つま先立ちになっちゃった pic.twitter.com/rjFBD6E4Sv

— かものはしくれ (@kamonohashi_kre) 2019年5月12日

屋外では原付、屋内では中型以上が展示されてたんだけど、(自分の知る限り)現在一般販売されている車種がほぼ全部網羅されていることにまず感動。

現行のCBだと1100が一番好き pic.twitter.com/9JXUh54uRh

— かものはしくれ (@kamonohashi_kre) 2019年5月12日

転倒しないよう車体が固定されているので、子供が好きによじ登っても大丈夫。

バイクの国内販売が低調なんてニュースはよく聞くけど「これかっこいい！」を連呼していろんなバイクに乗りまくる子供たち(＆その姿を写真に収める親たち)の姿はライダーの端くれとしてちょっと嬉しくなる。

自分も見てるだけじゃなく、ここぞとばかりにほぼ全車種の足つきチェックに勤しんでみた。

男性ながら161cmと小柄で超短足の自分としては、バイク屋さんのようなプレッシャー(コカさない・商談に持ち込まれない)のない場所で乗り心地を試せるのは非常にありがたい機会だった。

やれCBRは(買うつもりはないけど)思ったより前傾姿勢がキツくないなとか、なんだかんだCBはロマンの塊だとか、ゴールドウィングのシートの座り心地は最高だぜとか、レブルの両足ベッタリは癒やしとか、CRFとかアフリカツインみたいなのは無理線だなとか。

良くも悪くも「優等生」と言われるホンダ車だけど、やっぱ実車を前にするとどんなバイクでも「いいなあ」と思わせてくれるのは素直に実力の賜物だと思う。

他のメーカーもおんなじようなことやって欲しい。多分全メーカー好きになる。

モンキー125の「しっくりくる感」が半端なかった

で、ここからが本題。というか↑でほぼ完結。

50が生産終了になって125になって生まれ変わりました！ってニュースを見た時は「ほーん、見た目かっこええけど従来からのファンからしたらどうなん？つーか高っか」くらいの感想しか持ってなかったんだけど、いざ実車に跨ってみたら「オレメッチャおもろいで！」って直に語りかけられたような衝撃に襲われる。

カタログ上のシート高は775mmと高めだけど、車体の細さと軽さのおかげで足つきは良好。小柄な車体なのに太めのタイヤのおかげで接地感もすごい。

オリジナルは完全に「(当然いかがわしい意味ではない)大人のおもちゃ」の印象だったけど、125のサイズなら実用に耐えつつ(無理のない姿勢で普通に乗れる)遊び心も満たしてくれそうで、一言で言えば完全にフォーリンラブ。

とはいえ1週間前に俺カブ乗るわって記事書いたばっかりなのにそんなすぐ心変わりしてええもんか？と自分の意志薄弱っぷりに呆れもする。

ただカブ実際に跨った時は「ふーん、これがそうなんだ」くらいの感想だったのに対してのコレなので、スルーしてしまうのは勿体無いとも思うので、

比較していろいろ考えてみた

VS大型の時と違って、現実的に維持可能かの条件はどちらも満たしているが、その分心情的にはどちらも一長一短。

個人的に気になるポイントだけ抽出して比較してみる。

項目	スーパーカブ110	モンキー125
価格	275,400	399,600(ABSモデル432,000)
積載性	純正リアボックス他もろもろ付けられそう	純正ではリアキャリアのみ
デザインの好み	○	◎
航続距離(WMTC値×タンク容量)	69.4 × 4.3 ≒ 298	67.1 × 5.6 ≒ 375

まず先にも触れたけどモンキー普通に高い。ABSモデルだと今乗ってる中古のビーノとエストレヤの購入金額の合計とほぼ同じになっちゃうって。

カブならまだしも、モンキー125については出たばっかりのモデルなので中古の弾数も割引率もたかが知れているだろうし、この価格からガッツリ下がった値段で買えることはまずないだろうなと。

あとモノ積める余地がほぼ無さそうなのも弱み。通勤でも使うこと考えると雨ガッパくらいは常に積んでおきたいし、パーツ工夫すれば積めなくはないんだろうけど、それでも結果余計に足が出ちゃうのは間違いないし。

ただ純粋にかっこかわいい。カブのデザインもTHE 日本のバイクって感じがして好きではあるんだけど、面白みには欠けるというか。ここは完全に主観なのでどうとでもなる。

燃費については両者ともさすがホンダ車、って感じの数字でほぼ差はないんだけど、モンキーの方がタンク容量がデカい分航続距離伸びる＝給油の機会少なくなるのは素直に嬉しい。

田舎に行くとガソスタが土日休みだったりすることも多い(それで大三島で一度遭難しかけた)ので、給油に不安がないのは非常にありがたい。

..で、結局また決められない。こんな男と結婚する女は不幸だと思う。

こんな感じで、また悶々と日々を過ごすことにする。