2026年10月の素振り

これは何

2026年10月の単発の記事にするほどでもない雑多な話題をまとめている。

dachshundに楽曲検索を追加した

Spotifyでフォローしているアーティストの新着リリースを巡回するWebアプリケーションに、楽曲の検索とBPMやスケールなどの詳細情報の表示を追加した。

ただ、Audio FeaturesとAudio Analysisは、APIの変更により、Development modeのAPIキーでは利用できなかった。
すべての楽曲の音響指標がヒットするとは限らないのだが、ReccoBeatsを使うこととなった。

個人OSSのハードニング

昨今のセキュリティの問題を鑑みて、個人OSSで依存しているライブラリの更新と仕組みの変更を積極的に行っている。

npmからpnpmへ移行した

Node.jsのパッケージ管理をnpmからpnpmへ移行した。
pnpm 10以降では、依存パッケージのインストール時に実行されるスクリプトを制限することで、意図しないコードの実行を抑止できる。
当然ながら、コードそのものが安全になることはないのだが、暗黙的に何かが行われる心配が少なくなる。

ツールチェーンの管理をmiseへ移行した

個人プロジェクトで使うツールチェーンの管理を全面的にmiseへ移行した。
プロジェクトで前提としているツールチェーンとそのバージョンが設定ファイルに明示されるメリットがある。

Dependabotを有効にした

今までに設定ファイルの記載が億劫で消極的な導入ではあったものの、有効にすることのメリットがかなり大きくなったため、各リポジトリでDependabotを有効にした。

個人ScalaプロジェクトのScala Steward導入

基本的には上述のブログを参考にしたのだが、tibdex/github-app-tokenがdeprecatedとなっていたため、actions/create-github-app-tokenに移行した。

name: CI
on:
  schedule:
    - cron: '0 0 * * 0'
  pull_request:
  push:
  workflow_dispatch:
jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - name: Checkout repository
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # https://github.com/actions/checkout/tree/v7.0.1
        with:
          persist-credentials: false
      - name: Generate token
        id: generate-token
        uses: actions/create-github-app-token@64ab729a6294000f5aa4a4bc0b73d1f32bc45510 # https://github.com/actions/create-github-app-token/tree/v3.3.0
        with:
          client-id: Iv23liEOBr6doOzpifoo
          private-key: ${{ secrets.SS_PRIVATE_KEY }}
          owner: ${{ github.repository_owner }}
      - name: Use HTTPS for GitHub submodules
        run: |
          git config --global --add url."https://github.com/".insteadOf 'git@github.com:'
          git config --global --add url."https://github.com/".insteadOf 'ssh://git@github.com/'
      - name: Launch Scala Steward
        uses: scala-steward-org/scala-steward-action@3e5cae868160200afda12b57c150e56cede989ab # https://github.com/scala-steward-org/scala-steward-action/tree/v2.97.0
        with:
          github-token: ${{ steps.generate-token.outputs.token }}
          author-name: "stoneream-scala-steward[bot]"
          # https://api.github.com/users/stoneream-scala-steward%5Bbot%5D
          author-email: "347181854+stoneream-scala-steward[bot]@users.noreply.github.com"
          repos-file: 'repos.md'

(commit)

ARTEXによるペネトレーションテスト

個人で開発・運用しているWebアプリケーションに対して、ARTEX亜種であるところのartex-globalにて友人の環境から攻撃をしてもらった。

今回のテストでは、アプリケーション自体の脆弱性は見つからなかったが、サーバーのSSHのパスワード認証が有効になっていることがわかり設定の変更を行った。
また、Cloudflareを経由せずに、WebアプリケーションのオリジンサーバーのIPアドレスへ直接アクセスできることも発覚したため、ファイアウォールの設定の見直しも行った。

読んだ

詩人の手紙

ジョージ及びトマス・キーツ宛 1817年12月21、27（?）日

ディルクとさまざまな問題について論争ではなく考え合いをした。いくつかのことがぼくの心の中でぴったりと適合しあい、すぐに次のことが思い浮んだ。それは特に文学において偉大な仕事を達成する人間を形成している特質、シェイクスピアがあれほど厖大に所有していた特質、それが何であるかということだ――ぼくは「消極的能力（ネガティヴ・ケイパビリティ）」のことを言ってるのだが、つまり人が不確実さとか不可解さとか疑惑の中にあっても、事実や理由を求めていらいらすることが少しもなくていられる状態のことだ――たとえばコウルリッジは半解の状態に満足していることができないために、不可解さの最奥部に在って、事実や理由から孤立している素晴しい真実らしきものを見逃すだろう。

ベンジャミン・ベイリー宛 1817年11月22日

世界中の争いごとのほとんどの原因となっているものは何か？　それはこういうことにすぎない、ふたりの人間の心が出会い、お互いを充分理解するだけの時間がまだなかったために、どちらか一方の行為によってもう一方がショックを受けたり驚かされたりしてしまうということだ

「ネガティブ・ケイパビリティ 答えの出ない事態に耐える力」の感想に関連して、書籍に現れた「ジョン・キーツ」という人物について私は興味を持っていて読んだ次第。

彼の25歳というあまりに短い生涯の中で、親しい友人や家族に宛てて書いた魅力的な手紙がまとまっている書籍である。
文学・思想上の概念として提示したネガティブ・ケイパビリティについて、彼の頭の中を覗いてみたいとは思わないだろうか。
その手紙の一端からネガティブ・ケイパビリティについて何かしらの理解を深める内容が得られるのではないかと期待できるのではないか。

ジョン・H・レノルズ宛 1818年4月9日

デヴォンシャーは雨の日がつづいている。雨滴が窓にあたる時、それはまるで、溺れかかった悪魔を生き返らせるために差し出された一クォートの冷たい水のような感じがする――雨雲が大地に肥沃さを降り注ぐなどという感じではなくて、大地の根がずぶ濡れになって冷たく腐り果てているという感じだ

何らかの所感について、誰かが使った言葉を思考停止で言ってみたり、よくある平易な言い回しに頼ってしまったり、言葉では言い表せないことが私にはたくさんある。例えば、今年の9月に東京で雨が長く続いていたときには「ここのところ雨がずっと降っていて、なんとなく憂鬱～」といったところ。

彼の文章には情念がありありと深く刻み込まれていると思う。
どちらかというと、ネガティブ・ケイパビリティそのものよりも彼の表現に圧倒されるばかりであった。
彼には、キーツには、言葉で言い表せないことは無いのではないかと感じる。

実は彼の詩を読む以前にこの書籍を読んでしまったのだけど、詩集もぜひ読んでみようと思う。

キーツ詩集／中村　健二｜岩波文庫 - 岩波書店

おわり

お盆に帰省できなかったことと祖父の命日に合わせて今月に帰省した。 家族とは他愛もない話をしながら、のんべんだらりと過ごすことができてよかった。

季節の変わり目もあったのだろうか。
なんとなく外に出る気力が起きなかったため、映像作品を見たり、ゲームをして過ごしていた。

2026年9月の素振り

これは何

2026年9月の単発の記事にするほどでもない雑多な話題をまとめている。

RunPodでGPUを借りた

The AI Developer Cloud | Runpod

クラウドでGPUインスタンスを借りられるサービスで料金は従量課金制。
この頃はローカルで生成AIを動かすのが流行っているのを観測している。
自分のPCではそれほど大きなモデルを動かすことができないのと、DGX Sparkに手を出すほどお金持ちではないからうってつけのサービスということ。 ComfyUIやらJupyterLabをシュッと立ち上げるテンプレートが用意されているのも旨味。

ComfyUIに関しては、モデルを管理するためのマネージャーも付属していてLLMから画像生成まで各種モデルをノーコーディングで検証できるのが良かった。
いわゆるガードレールの外れたモデルを試してみたものの、システムプロンプトをそれなりに頑張らないと日本語で使うのが難しそうだった。
とはいえ、ChatGPTでは弾かれそうな内容にもポンポン答えてくれて愉快だった。

生成AIを使ったサービスを作りたいと考えている。
RunPodを使ったのは、GPUの性能や応答速度のベンチマークを取り、実現可能性なんかを探るためだった。
普通に考えたらOpenAIやらAnthropicのAPIを使えば良いのだが、扱う情報がセンシティブであるという点からローカルLLMを用意する必要がある。
（今のところは詳細を書けないが、今後の記事で書くかもしれない。）

読んだ

逆説のスタートアップ思考

新卒で入った会社がまさにスタートアップで、そこで関わった人たちの考え方と本の内容が重なる部分が多かった。
私にとっては当たり前だったことが、一般にはそうでもなかったのかもしれないと思った。
スタートアップを経験したり、そういう界隈の人たちは「なんだかんだ失敗することもあるよね～挑戦できた素晴らしい！！」という文化があると思っていた（あるよね？）。
ベンチャーキャピタル側にもそれを許容する場合があるという点は興味深かった。

ベンチャーキャピタルはヒットを狙うビジネスではなく、ホームランを狙うビジネスなのです。 ベンチャーキャピタルの言う「成功」とは、投資のヒット率ではありません。失敗の頻度より、正しかったときの成功の大きさが重要であり、「失敗を気にせずに大振りしなければ行けない」ビジネスです。つまりホームランを打つことだけが重要で、ヒットや三振は彼らにとって意味をなしません。

帝王の殻

あらすじをサックリと引用。

火星ではひとりが一個、銀色のボール状のパーソナル人工脳を持っている。各人の経験データを蓄積をするこの人工脳は、巨大企業・秋沙能研に制御され、人工副脳となるのだ。そして、事実上火星を支配する秋沙能研の当主は「帝王」と呼ばれていた……。人間を凌駕する機械知性の存在を問う、火星三部作の第二作。

ボール状のパーソナル人工脳（作中では「PAB」）と共に暮らすことが当たり前になっていて、データを蓄積するだけではなく、当人の分身のように振る舞い、本人に代わって判断や発言までできるという世界観。
各種AIサービスが生活に馴染みつつある今日この頃。そんなちょっと先の未来が描かれているようだ。

小説の中では、PABの発言と自分自身の考えのどちらがホンネなのかわからなくなっている様子が印象的だった。

アイサックが実用化されたら、PABを通じて、その持ち主の心の内がわかるようになるかもしれない。心を読むということだ。しかし、読むことと、その内容を理解したり共感するということは別の能力だ。

AIに判断や発言、もっといえば思考、いやもっといえば自我を明け渡してしまってはいないだろうか？

おわり

9月は天候の悪い日が続いていて外に出かける機会が減った。
体調が良くなってきたため、久しぶりにランニングを再開しつつあるのだが、以前のようには走ることができず明らかに体力が衰えていることを実感するばかり...。 10月は晴れの日が多いらしい。期待。

2026年8月の素振り

これは何

2026年8月の単発の記事にするほどでもない雑多な話題をまとめている。

SMTPリレーを設定した

個人で立てているRedmineやらGROWIからメールを送りたいと思っていた。
自前で真面目にメールの設定をするのはとにかくダルいということで、SMTPリレーを使うことにした。
サービスは、SMTP2GOというもので無料枠で間に合うといったところ。

タスク管理をNotionからRedmineへ移した

Notionでカンバン式で管理していたタスクをRedmineへ移行するため、notion-redmine-migratorを作った。
NotionのデータソースをJSONへダンプし、Redmineのチケットへ変換するものとなっている。

というのも、Notionは良くも悪くもいろんなことができすぎてしまう点に、ぼんやりとした苦手意識が長らくあった。
枯れていてシンプルに使えるRedmineが好きで移行に成功。これで脱Notionできた。

ai-dotfilesのスキルを手入れした

以前に公開したコーディングエージェント向けのスキル群を一通り見直した。

主に、脅威モデリング、セキュリティテスト設計、ソフトウェアセキュリティ実装、ソフトウェアサプライチェーン分析といった、セキュリティ関連のスキルを重点的に組み込んだ。
その他、lycheeでリポジトリ内のリンク切れを検査できるようにした。

読んだ

死に至る病

友人からの推薦図書である。
生きることそのものに伴う苦しさについて考えたい、という期待を持って読んだ。

「死に至る病」とは絶望のことである、という一節から始まる。
さて、絶望とは...。多様な絶望について淡々と語られている書籍だと思った。

無限性の絶望は有限性の欠乏に存する

人間は「別の自分になれる」「こういう生き方もありうる」と想像できる一方で、実際には身体・時間・境遇など、有限な条件の中で生きている。
ただし、その可能性ばかりが広がって現実の自分と乖離していくことはままある。常にある。
可能性ばかりが膨らんでいくと、「無限性の絶望」と感ぜられる。
逆に言えば、有限性は制約ではなく、想像された自己を具体化する？
「もっと別の自分でありえたのではないか」と思うこともあれば、「自分にはこの現実しかない」と感じることもある。

ギャップというべきか、人間が生きる以上どこかで経験する普遍的な苦しさは日常的にある。

いわば絶望への思いを求めて、全人格をして絶望に共鳴せしめんとして戦う。

たった一つのことについて大きな戦慄を感じたとき。
なんとなく自分自身が感じているコンプレックスが総動員されてしまうヒヤッとする瞬間。
絶望をできるだけ避けたいと普通は思うだろうけど、絶望と自分自身を一致させてしまう妙な性質を人間は持っている。

「第一章　自己意識の諸段階（「神の前に」という規定のもとにおける）」と「第二章　罪のソクラテス的定義」

第一章から引用

罪とは、人間が神の前に絶望して彼自身であろうと欲しないことないしは人間が神の前に絶望して彼自身であろうと欲することである。

第二章から引用

だがソクラテスの罪の規定のうちに含まれている真理を看過することは我々には決して許されない、むしろ我々のような時代にはそれを先鋭化しなければならないのである。

ただ漠然とした絶望があったときに、それと対峙することはとても苦しい。
自分という存在が何によって成立しているのかを認めず、自分自身との関係を自分だけでどうにかしようとする。
知ろうとしない、分かっているのに認めようとしない、分かったことに従おうとしない。
自分自身と向き合うことを怠ったことが積み重なると、精神的な意味で死にたくなり、実際に死んでしまうかもしれないと思うだろう。

補足的な感想

キェルケゴールの出自にはかなり強いキリスト教的な背景があるようで、宗教に馴染みのない私にとってなかなか読み砕けないものだった。
西洋の哲学書はそれらの文化とかなり紐づいているし、キリスト教を学ぶことは汎用性の効く知識なのかな。

さよなら、インタフェース 脱「画面」の思考法

文章は語り口で愉快！
とはいえ、なんだか悪く言えば昔話を聞かされているようにも思えた。
良く言えば、歴史書に近い。

コンピューターに対してかつて何が夢見られ、それがどのように歪んでいったのかを物語として追っていく。
アンチパターンと本来あるべき理想について書かれており、同じ轍を踏まないための実践的な教訓を得た。

Keyの軌跡

想定読者であろう「鍵っ子」から私は大きく外れているかもしれない。
というのも、Keyの作品については、物語よりも音楽に思い入れがある。
音楽だけを知っていて、作品を履修していないものが多くある。
実際に書籍では、作品の音楽に相当な熱意が込められている旨が述べられていて納得感があった。

少し興味深かったのは、複数ルートを辿るゲームをアニメ化する難しさについて述べられていた点である。

ビジュアルノベルの場合は「作品中に複数のヒロインのルートが存在する」、つまりはマルチエンディング形式を備えていることが前提となる。しかし、アニメ化する際にまずヒロインＡを恋愛対象として攻略し、次にＢを、さらにＣを攻略していくという形をとるとすれば、主人公は何度もスタート地点から物語をやり直すことになってしまい、視聴者は時系列的な違和感を覚えてしまうため、物語世界に没入するのは難しい。

物語の考察について述べられているのを読むと、あぁ懐かしいなあ～となるばかりであった。 そういえば昨年はAIRのリリースから25周年でしたね。

佳乃の手作り五目焼きそば（聖が手伝った）

追記で書いておくと、ビジュアルノベルゲームの評価として俯瞰したときに、この書籍のKeyについての評価がやや誇張されているんじゃないかなって節はあるように思った。

不器用で

ラランドのニシダさんが書いた小説とのこと。
友人に教えてもらって読んだ。

「不器用さ」は、神経質さや感受性の高さと繋がっているんじゃないかと考えた。 登場人物たちはあまりに繊細で、それゆえに不器用だった。
生々しいほどの生活感と素直な気持ちが描かれていて、楽しく読むことができた。

試みの地平線 伝説復活編

この書籍の感想を記事として書くのは少し憚られるような気がするが、真面目にこのブログを読んでいる人はいないだろうという前提で書いてみることにした。

令和のこの時代になかなかこういう文章に触れることは少なくなってきている。 字面だけを追いかけると、トキシック・マスキュリニティと捉えられる表現がある。
性的なサービスや性体験を促すような物言いに同意するわけではない。

そのうえで、鬱屈とした人間に、突拍子もなく心を揺さぶられるような体験をしてほしい、ということだと私は読んだ。
過激な物言いだからこそ、抑うつ気味な私にとってはショットガンのような面白さがあった。
字面と伝えようとしていることのあいだには、大きな隔たりがある。
これは自己啓発本だと思っているけど、今まで読んできた自己啓発本の中でも最も行間が詰まっている。

以下は、補足的に見ると面白い動画です。

世界史を勉強していた

唐突に歴史を学びたい。
学生時代は歴史の授業を選択していなかった背景もある。

とりあえず入口として、NHKの「3か月でマスターする世界史」を視聴していた。
歴史とは戦争の血の跡なんだなあと、ぼんやり思った。

その中でも、モンゴル帝国の時代が興味深かった。
もちろん、いろいろな視点があるだろうし、征服された側から見れば、その暴力性を無視することはできない。
それでも、宗教的な多元性を認め、多様な人々を統治に取り込んだ寛容さには惹かれた。
放送中の「天幕のジャードゥーガル」ともつながり、北方謙三の「チンギス紀」を買った。
アニメも小説も史実とは異なる部分と脚色があるだろうが、関心を深めるきっかけとしては愉快なのではないかと思う。

モンゴルの時代に限らず、ほかの歴史上の出来事についてもdigり甲斐がありそうだ。

おわり

気胸になり一週間ほど入院するアクシデントがあった。
もともとの持病に加えてこんなことまで起きるなんて、泣きっ面に蜂と言える。
退院後はいつもの通りに軽度の運動をしたり、本を読んだり...落ち着いて過ごしていた。

地元の羽黒山にでも行って、お祓いしてもらいたい気分だ。

2026年7月の素振り

これは何

2026年7月の単発の記事にするほどでもない雑多な話題をまとめている。

dachshundを公開した

以前に作ったsamoyedの後継にあたる。
主な機能は、Spotifyでフォローしているアーティストのリリース情報を巡回し、新着リリースを探すことである。

samoyedも同様の機能を持っていたのだが、バグが多かったことに加えて、依存していたMonixの最新リリースから時間が経っていたため、そのまま使い続けることに不安があった。

大きな変更としてはWeb上の管理画面を作った点である。

ジョブの処理状態も確認できるようにしている。
APIのレートリミットに達した場合などは、再試行時刻を保存して時間を置いて処理を再開するため、待機中のジョブが発生する。
詰まり具合を確認するたびにDBを見に行くのが面倒だったため、Webから確認できる画面を作った。

新着リリースをプレイリストに投入する機能がものすごく便利。
作業BGMには困らなくなった。

ユーザーがフォローしているアーティストの同期や、各アーティストのリリース情報の取得はバックグラウンドジョブとして動作している。
今回はZIOを使用してバックグラウンドジョブの実行基盤を作った。
各ジョブはZIOのfiberとして並列に起動し、設定された間隔で繰り返し実行される。
具体的な詳しい実装内容は割愛するが、DB上に処理対象をキューイングしてグルグル回している。

github.com

プロジェクトの構成としては、コーディングエージェントが走り回りやすいように、各種ツールチェーンとドキュメントを割と丁寧に整備したつもり。
個別機能の実装にはAIをかなり使ったが、要所、要所では当然手直しをしている。

github.com

ユーザー固有の情報を取得・操作するには、クライアントクレデンシャルフローではなく認可コードフローが必要になる。
Spotifyの認可コードをアクセストークンへ交換し、アクセストークンとリフレッシュトークンを暗号化してDBに保存している。
アクセストークンの期限が切れる前に、リフレッシュトークンを使って更新する大変にお行儀が悪い処理・ジョブも動かしている。

自分で使うものを自分で作りたい

Tシャツを作った。創作活動名義で作ったものなのでデザインは割愛。
昨年の秋にリリースしたアルバムをモチーフとしたもの、とだけ...。
ボディにはShaka Wearを使った。ヘヴィーウェイトな感じになっている。
着心地も含めて、ものすごく納得感のあるTシャツになった。

5、6年ほど創作活動を続けてきたが、長らくアーティストとしてのロゴがない状態だった。 ステッカー制作への関心をきっかけに、今回作ってみることにした。
以前に読んだ「レタースペーシング - タイポグラフィにおける文字間調整の考え方」が役に立った。

作ったロゴを使い、テンプレートに沿ってステッカーを入稿した。
一応形にはなったものの、デザインにはまだ納得がいっていない。
今後も間違えながら、少しずつ勘所をつかんでいきたい。
間違えるたびに数千円が飛んでいくのは授業料？

その他にも小物類やTシャツ以外の制作にも挑戦したいところ...!!

読んだ

渡辺一夫評論選　狂気について

以前に読んだ「ネガティブ・ケイパビリティ 答えの出ない事態に耐える力」で渡辺一夫に触れられており、もう少し知りたいと思って読んだ。

技術書や実用書ばかり読んでいる私にとって岩波文庫にはなんとなく敷居の高さを感じている。
実際に本書でも、フランス文学や当時の歴史について読者が知っている前提で話が進む部分があり、勉強不足な私には何について話されているのかわからない状態がしばらく続いた。
真剣に読み解くなら、その都度に参考文献を開く必要があったのかもしれない。
今回はそこまでの体力がなく、いつかわかるようになるだろうと思って字面だけを追いかけた。

プログラミングを始めたばかりの頃に、最初から#include <iostream>の詳細を調べなかったのと同じようなものだと思っている。

寛容が不寛容を打倒するために不寛容へ変わってしまう構図が興味深かった。
自分だけは正気であると思いたくなるが、理想を追い求めること自体が別の狂気につながる可能性はある。
「天使になろうとして豚になりかねない」という言葉は、そういった人間の不完全さを端的に表しているように感じた。

全部を理解できたとは到底言えないものの、今の時点で引っかかった言葉を覚えておけば、別の本を読んだときにつながることもあると願いたい。

おわり

7月は持病が悪化して、ほとんど寝込んでいた。
気分が悪いと本が頭に入らないし、プログラミングだってできなくなってしまう。
「体が資本」とはまさにその通りである。

2026年6月の素振り

これは何

2026年6月の単発の記事にするほどでもない雑多な話題をまとめている。

CodexでPRの作成とコードレビューをしてもらう

Codex では、GitHub 連携したリポジトリをチェックアウトし、任意のセットアップを済ませたコンテナ上で Issue 対応やコードレビューをしてもらえる。

何も設定していないコンテナでは、一般的に開発でよく使われるツールチェーンは入っている。
ただし、Scala の実行環境や細かいコマンドラインツールは存在しないケースが多い。

プロジェクトで必要なツールを明示しておく手段として mise を使う選択肢がある。
人間にとってもエージェントにとっても同じ環境を使う前提ができるので扱いやすい。

また、Codex の環境設定ではカスタムセットアップスクリプトを指定できる。
Web 上で長いセットアップスクリプトを直接管理するより、リポジトリ側にセットアップスクリプトを配置し、Codex 側では用意したスクリプトを呼ぶ作りにしておいたほうが運用しやすい。

加えて、開発中によく使うコマンドは just のレシピにしておくと便利。
test、lint、fmt、build のようなレシピを揃えておくと、こちらも同様に人間もエージェントも同じ入口で作業を進められる。

実際にはリポジトリを見てもらうのが早いのだが、プライベートリポジトリのため今回は詳細を割愛する。
後日のブログで公開できたら...と考えている。

初めてのMCP開発

foldory というものを作った。
今さらながらに「MCP を作るというのはこんな感じか〜」という体験ができたのは良かった。

任意のディレクトリにテキストファイルを書いたり、階層を作ったりできる単純な MCP。
エージェントが必要なタイミングで記憶として取り出せるようにしている。
複数の文脈を横断する場合に今のところは便利に使っている。

n8nを止めた

「2月の素振り」で導入した n8n だったのだが、結局使い道が思いつかない上に、ちょっとしたツールを書くにしても手で書いたほうが早いことが多かった。

AI エージェントとの接続がシームレスであるという点については、それはそうなのだが AI を使わなくてもできることのほうが私の場合は多かった。

承認駆動ワークフロー を消した

そもそもこのスキルを作成した背景として、初期のCodexにplanモードがなかったためである。
これからは初手で Shift + Tab を押して、積極的にplanモードを使っていきましょう。

コンテナのハードニング

大きく分けて4つの設定がある。

security_opt:
  - no-new-privileges:true
cap_drop:
  - ALL
read_only: true
tmpfs:
  - /tmp

Docker Compose を扱う場合に、侵害されたときの被害をできるだけ最小限に収めたい。
よって、上述のような設定を逐次反映している。

no-new-privileges はコンテナ内のプロセスが実行後に新しい権限を得られないようにする設定。
cap_drop: ALL は Linux capabilities をまず全部落とす設定で、必要になったものだけ cap_add で戻すことができる。

それぞれの capabilities でできることは上述を参考にしてもらうとして、デフォルトで有効になる capability も Docker のドキュメントにまとまっている。

read_only: true は、コンテナのルートファイルシステムを読み取り専用にできる。
（もちろん、指定されたボリュームには書き込み可能）

ただし、アプリケーションはログ、キャッシュ、一時ファイル、PID ファイルなどを書き込むことが往々にしてある。
今回は最低限の逃がし場所として /tmp だけ tmpfs で許可するといったことができる。

Windows と 1Password と SSHエージェントのフォワード

普段使用している Windows マシンから別の開発マシンへ入り、その先で GitHub などに SSH 接続したいことがある。
そのために、Windows 上の 1Password の SSH エージェントを接続先から参照できるように ForwardAgent を使った。

毎回の接続で ForwardAgent を有効にする場合、Windows 側の SSH config に書いておく。

Host dummy1
  HostName 192.168.10.10
  User user
  ForwardAgent yes

Host dummy2
  HostName 192.168.10.11
  User user
  ForwardAgent yes

秘密鍵を各マシンへ配らずに済むため、鍵管理の見通しがよくなる。
一方で、接続先からエージェント経由の認証が使えるようになるため、どの接続で ForwardAgent を有効にするかは雑に広げないほうがよさそう。

Tailscale を入れた

ローカルネットワーク内で利用していた開発マシンに、外からも内部の環境へアクセスしたくなった。
その候補として Tailscale を試した。

JetBrains のリモート開発を組み合わせると、手元のマシンのリソースをほとんど使うことがなく開発できるのが便利。

読んだ

ゆとりの法則

忙しい現場や機能不全がどのように負の連鎖を生むのかを扱っている本に読めた。
プロジェクト管理の本ではあるが、単にスケジュールや見積もりの話だけではなく、人間がどのように疲弊していくのか、組織の余裕がどのように失われていくのかが書かれていて興味深かった。
実際にそれ起きていたり、予兆があると現場としては黄色信号と見てもよさそう。

人間は時間的なプレッシャーをいくらかけられても、早くは考えられない

あと「この人がいなくなったらヤバい」とか「この人の後継となる人物がいるか？」っていう人的資源が、いろいろな面で深刻なリスクに見えた。 書籍では次のような簡易な式が。

人的資本 = 普通の速さで仕事ができるまでの期間 x (給与 + 間接コスト) x 50%

「属人化をなくす」は普通の速さで仕事ができるようになるまでにかかる時間もコストを圧縮するための投資だったりリスクヘッジとも思える。

エンジニア育成現場の「失敗」集めてみた。

なんだかんだ後輩や新入社員のオンボーディングに関わる機会が増えていることもあり読んだ。
失敗事例を読むこと自体も有用だが、それ以上に自分が誠実に振る舞えているかが気になっていた。
以下の項が興味深かった。

「ここに自分の人生を託せるか」

1日に大体は8時間前後働いているという前提で、仕事は人生のなかでかなりの時間を占めている。
というわけで、伸び代を伸ばしてもらえるか、人生において実のある機会を与えることができるか。
うっすらとこちらとしても責任を感じるわけで、明るい未来だとか見せられるかって大事だよねって思った。

「期待されているのにその期待がわからない」 / 「業務の目的と価値を書き下す」

期待されるタスクの質だったり内容をすり合わせておくのは大事だけど、いわゆる「ちゃんと」ではなく期待値を具体的に合わせることができている状態。
クオリアじゃないけどお互いに近しいものを見ている状態が好ましい。
言ってることはわかるんだけど、実践することは難しいし往々にしておかしな方向に転がっていってしまいがちなのが現実だと思う。

「企業にとって成果以外はすべて負債」

個人的には和気あいあいとメンバーがお互いに気持ちよく仕事できる状態が好ましいよねって思っている。当然だ。

ただ、その話を友人としていたら「結局はアウトプットがないと意味ないよね」って話をされて、魂の形が違うと思った。
が、言ってることは正しい。色々な気持ちが交錯している今日このごろ。

「応募者は自分自身をも騙すことがある」

これは私が転職活動しているときにも多分起きた気がする。 いろいろな会社を受けていると、発言に対するインプレッションをなんとなく察して、別の会社では言い方を変えている節があった。 面談を行う上でも、そのような「ウソ」といったら言い過ぎだし失礼だけど、見抜く術とか捲る技術って大事そう。 ただ、私自身は採用に関する業務を行っていないから適当言ってます。

セキュリティ周りで読んだもの

感想は割愛するが「セキュリティエンジニアの教科書」を読んでから参考文献として挙げられているものと周辺の資料を読んだ。

いい加減にMITRE ATT&CKを読むか〜って思ったり、ここから派生して読みたい資料が増えた。

おわり

今月はめまい、立ちくらみ、真っ直ぐに歩けない、呂律が回らないなど散々な目に遭った。
長らく精神病と付き合っているが、これはこれで初体験。
脳梗塞なのではと心配になって、#7119に電話をかけて相談をしたら救急車が病院に運んでくれた。
結局のところ私生活に問題があり、脳に原因があるわけではないということがわかってよかった。
7月も7月で休養を意識して過ごしたい。

2026年5月の素振り

これは何

2026年5月の単発の記事にするほどでもない雑多な話題をまとめている。

shokushitsu のアップデート

「shokushitsu」についてはこちらの記事を参照されたし。

リスト表示する内容が見切れてしまう問題に気がついたため、ウィンドウの高さを考慮してページングする修正を加えた。

読んだ

ユニコーン企業のひみつ

組織、チーム、プロジェクトといった、複数人で仕事をしていくことへの関心が個人として強くなっている。
全体としては、テック企業における組織文化、ロールの定義、立ち振る舞いについて書かれている。

Spotifyの事例が取り上げられているが、当然ながら全く同じ文化や仕組みをそのまま持ち込めるわけではない。
どのようにやるかというより、なぜそういう仕組みが必要だったのか、何を守るための文化なのかという部分が抽出されている。

以下、引用。

文化や価値観を守るためには、気が進まない局面であっても行動をとる。なぜなら、文化は流れていくに任せてしまうと、取り戻すのが難しくなってしまう。だからこそSpotifyはその文化を強めることに力を入れているのであり、職場に文化が息づくことに多大な労力を費やしている。

気持ちよく仕事ができるのがイチバンですね。次に倒産しないことです。

グラフィックデザインにおける秩序と構築

以前から引き続き、「小手先のデザインの引き出しを増やしたいな〜」ってくらいの気持ちで読んだ。
実際にはデザインによって人の情念をどのように扱うか、そのために社会学や心理学、時勢のようなものまで使っていく発想をもたらしてくれる本だった。
受け取り手に対してどう心情を仕向けるか、という観点で興味深かった。

上述の理由もあり、参考文献として社会学、経済学、心理学に関するものも多く含まれている。
最近の関心領域に被る分野でもあるためお得感がある。

重ねて、重ねていうと...Webデザインについて期待して読むと、少し齟齬があるかもしれない。
汎用的に使えるテクニックはあるものの、雑誌、新聞やフライヤーのような印刷物を例として挙げる内容が多かった印象。

セキュリティエンジニアの教科書

時勢柄、実務でもセキュリティに本腰を入れる機運が高まっている。
セキュリティエンジニアに転向するわけではないものの、バックエンドエンジニアとしてセキュリティ意識を引き締めたく読んだ次第。

情報処理技術者試験の対策で教科書的には「機密性」、「完全性」、「可用性」の3要素が頭に叩きこまれることが多いのだが、本書ではそれに「真正性」、「責任追従性」、「否認防止」、「信頼性」を加えた7要素が紹介されていた。
説明されてみれば、「確かにそうだよね」といったところだが具体と照らし合わせると整理しやすい。

以下は引用。

特性 セキュリティ対策の例
機密性
（Confidentiality） 		・高度なセキュリティ対策が導入済みのデータセンターへサーバー機器などを保管
・強固なパスワードポリシーを適用して、ブルートフォース攻撃による不正ログインを防止
・アクセス制限機能を実装して、権限のないユーザーによる情報の閲覧を防止
完全性
（Integrity） 		・アクセス制限機能を実装して、権限のないユーザーによる情報の変更を防止
・暗号技術を用いて情報を暗号化して改ざんを防止
・バックアップの取得（完全性が失われた場合の復旧手段）
可用性
（Availability） 		・情報システムの冗長化
・予期せぬ停電など電源障害が発生したときに一定時間電力を供給する無停電電源装置（UPS：Uninterruptible Power System）の設置や信頼できるデータセンターの利用
真正性
（Authenticity） 		・多要素認証、生体認証の利用
・公開鍵暗号基盤（PKI）、セキュアチャネル（TLS）の利用
責任追従性
（Accountability） 		・アクセスログ、操作ログなどのログの保存
・情報システムの正確な時刻情報の維持
・アカウントの使いまわしを防止するための適切なアカウント管理
否認防止
（Non-repudiation） 		・アクセスログ、操作ログなどのログの保存
・情報システムの正確な時刻情報の維持
・公開鍵暗号基盤（PKI）の利用
信頼性
（Reliability） 		・情報システムの誤操作や誤動作が発生したときに、安全な状態にする考え方であるフェイルセーフを前提とした設計
・情報システムの十分なテスト

私が考えていたよりも「セキュリティエンジニアとしての役職」について説明されており、セキュリティマネジメントも確かに実務として存在するもののここまで細分化して考えたことがなかったな〜と思った。
なんとなく私のような未熟な開発者としては、脆弱性やセキュア開発といったテクノロジー寄りの話題に意識が向きがちなものの、組織としてリスクの捉え方と管理はかなり重要そう。

そうかもしれない。

ネガティブ・ケイパビリティ 答えの出ない事態に耐える力

この言葉になじみがなければないほど、読んでみてほしいと思った。

ネガティブ・ケイパビリティの概念について雑に説明すると、間に合わせの解決策で帳尻を合わせず、あえて中ぶらりんの状態を保つ能力というものと理解している。
その観点で日常に収まるような規模から、もう少し大きく広げて社会的な現象まで、答えの出ない場面に直面することは多い。
（そんなこと言ってられない話題と場面もなんだかんだあるけど...）

寛容さについて述べられているが、今の世の中にそれはあるだろうか、むしろ昔にはあっただろうか。
そして、私にはあるだろうか。
概念を理解していても、それを実践するのはすごく難しい。

それはそうと、概念を理解するために具体の話題で構成されている。
その中でも興味深かったのは、詩人であるジョン・キーツ、文学者である渡辺 一夫、人間の脳のわかりたがる性質について。
関連書籍をdigって行きたい所存。

おわり

5月はゴールデン・ウィーク明けにガッツリ風邪を引いてしまいダウンしていたため、技術的な素振りがあまりできなくて読書と映画鑑賞をして過ごしていた。できるだけ休むことを意識して暮らしていたけど、思うようには本調子ではない。
最終週に徐々に回復の兆しがありつつも、6月も力を抜きながら自分のペースを取り戻していきたい。
そろそろ梅雨入りっぽい天気予報になっていて、外出は最低限にしたいところ。休むにはちょうどいいかも？

2026年4月の素振り

これは何

2026年4月の単発の記事にするほどでもない雑多な話題をまとめている。

shokushitsu のアップデート

「shokushitsu」についてはこちらの記事を参照されたし。
私には過集中のクセがあって、50分おきに休憩を促す機能を追加した。
その他には、大きな機能追加というよりも、コーディングエージェントが生成した冗長な実装を整理するなどした。

コーディングエージェントのスキルを公開した

この記事を読んでいる方々にとっては釈迦に説法かもしれないが、頻出する作業のプロンプト入力をショートカットするための機能と認識している。
あくまでプロンプトのためエージェントが命令に従うかというとそうでもないというのが実情。
LLMの出力を私の価値観に仕向ける機能として扱っている。
よって、これらのスキルを見せることは自分自身の思想と価値観を開示することと同じで抵抗があったのだが、信頼できる身内同士で公開することでありがたがられることが多々あって、メリットのほうが大きいと判断して公開することにした。

承認駆動ワークフロー

1つ実験的に試しているスキル。

生成・評価・改善・蓄積のフィードバックループによって、AIを自律的に働かせる仕組みが重要という話はよく耳にする。
カーゴカルト感が否めないのだが、百聞は一見に如かずということで個人でPoCレベルで実践したいと考えて作成したスキル。

再考！令和の情報ジャンキーの生存戦略

インターネットはかつて真実に近づくための手段と考えられていた。
現況としては、嘘や誤った情報を拡散する構造に変化している。
生成AIの到来でさらに見分けのつかない情報が増えており、結果として人々は何を信じてよいかわからない状態に置かれている。
すべての情報がすべての人に開かれていて、世界で起こったことがログに残って、アクセスできるものがインターネットだと解釈している。
ただある程度にそうなった結果としては、情報の陳腐化が加速した虚無感がある。

以前に「令和の情報ジャンキーの生存戦略」について書いた。
当時はレコメンドシステムによって、時系列の情報を追いかけることが難しくなってしまったことに課題感を持っていた。
その対策として、知り合いと知り合いの知り合いくらいの間柄の人にクローズドなコミュニティへ集まってもらい、情報を共有する場を運営（？）していた。
これはある程度には成功したのだが、ブログやニュースのように単方向な情報ではなく、双方向のコミュニケーションが発生するため人間関係の摩擦が生じるようになってしまった。
今後もそういった出来事と向き合っていかなければならないのかと考えた瞬間に気分がすごく落ち込んだ。と、同時に自身の未熟さもなんとなく痛感。コミュニティは解体した。
今のところは付かず離れず...友人たちとは必要に応じて個別に連絡を取るスタイルに着地した。

少し話を戻す。
情報を疑う防御姿勢みたいなものを求められる頻度とそのコストが明らかに上がっている。比喩的に言えば、何かに出くわす度に出会い頭で殴るくらいの疑い方をしている。
情報を得る経路、媒体としては編集さんが入っていて品質がある程度に担保されているハズ！と思われるもの。具体的には雑誌や書籍は、現在のところ相対的に心理的なコストが低い。

クオーターライフクライシス

26歳になった。25歳と26歳は20代の後半という点では1年しか変わらない。
誕生日の前後、その1日で特に大きな変化があったわけでもないのだが、鏡の前に立った私が突然に老け込んでしまったように思えた。
若さの象徴が失われていくことに対して、焦燥感を覚えるばかりであった。今のうちにやっておいたほうがいい失敗がもう少しあるんじゃないかと思える。

自分自身に対して理想を持ちすぎている自覚があって、それが現状と乖離していることから発生している感情と解釈している。
そこにかなりのフラストレーションはあるものの、考え方を捻じ曲げたら貪欲さが失われていないことが確認できたのは良かった。

読んだ

systemdの思想と機能

上述の記事を読んでから個人のサーバーでは、cronからsystemd timerに移行を進めている。
なんとなく深掘りの余地があるというか、深掘りの余地しかないため読んだ。
直近で込み入ったunitを書く予定があるわけではないのだが、知らないディレクティブとオプションを山ほど知ることができて楽しめた。
とにかく何かとログを残してくれるのはとても便利。

エンジニアのためのマネジメントキャリアパス

「ハーバード流交渉術 必ず「望む結果」を引き出せる!」に続いて、人間に関する本を読んでいる。直近のお仕事をにおいて処世術をもっと増やしていく必要に駆られているため。
自分自身のキャリアの選択肢として2つのルートがあると認識している。技術者として一点突破するか、マネジメントや調整も含めてオールラウンダープレイヤーとしてよしなに立ち回るか。
プログラマとして働いている。若輩ながらも。
後者は積極的には選択しないと考えていた。とはいえ、実際に経験してみないと向いている役割であるかを判断しかねる部分がある。なんだかんだ前者のルートであっても、意思決定にはそれなりの視座の高さを求められていると思っている。

それはそれとして、これまでの上司の行動や判断や組織中で求められていた役割を振り返ってみると、説明のつくものが増えて面白かった。

パスキーのすべて

色々あってパスキーに関わり合いになる今日このごろ。
なんだかんだ実装自体は、IDaaSに依存していて手を動かす部分の少なさに物足りなさを感じていて読んだ。
ユーザー体験に重きを置きながら網羅的にまとめられていて、自前でパスキーの認証を構築するには良い書籍なのではないか。

おわり

4月は自分のペースで生活することに失敗してしまって、現在地点や先行きを見失って視野狭窄気味になっていて色々なバランスが大きく乱れた。
5月は壊れたものを直すというか、ペースを取り戻すことを意識したいと考えている。
よって、手始めにゴールデンウィークは家族や友人に会うために福岡や大阪に何日か滞在してコンピューターからは離れて過ごしていた。一緒に時間を過ごしてくれた人たちにとても感謝している。

皆さまはいかがお過ごしだったでしょうか。