sonohen's tech blog

Google Pixelのデスクトップモードでブログを書いてみるテスト

Sun, 12 Apr 2026 00:00:00 +0900

私のスマートフォンは、Google Pixel 10 Pro Foldです。USB-C HDMIケーブルで外部モニタに接続すると、あたかもパソコンかのように使うことができます。今はこの機能を使い、かつ外部キーボード（MOBO Keyboard 2）とマウス（Logicool MX Vertical）を使用してこの記事を執筆しています。

また、このブログはHugoで作成されており、その元ネタはすべてGitHubに保存されています。つまり、ブラウザでGitHub Codespacesにアクセスして記事を書きコミットすれば、自動的に公開されるのです。

執筆中の画面はこんな感じです。

この仕組みをうまく使えば、外出先からでも気軽にブログ記事を書くことができるので便利です。

Claude CodeでオウンドメディアのAI編集部を立ち上げてみた

Mon, 23 Feb 2026 00:00:00 +0900

※ この記事は、誤字脱字、表現の冗長さ・曖昧さのチェックのためにClaude Codeを利用しています。

TL;DR

Claude Codeの SKILL と AGENTS を使い「マネーブログ　AI編集部」（オウンドメディアの編集部、うまくいけばアフィリエイトでお金儲けしようとした）を構築した。人間が事業計画・役割・ワークフローを定義し、Claude Codeがそれを実装するという役割分担で立ち上げた。
編集長AIに課した承認条件が厳しすぎ、編集者AIが指摘を受けては記事を修正するループが止まらず、コンテキストを食い潰した。これは承認条件を緩和し、完走できるようになった。
しかし、執筆された記事はいかにもAIが書いたような文体になってしまった。どのような文体で表現して欲しいのかを明確に定義しておく必要があったと考えている。
「事業計画を定義し、その評価基準でAIの成果物を評価する」という構造設計は成立した。ただし、今回はコンテキストの消費量が多く、セッションの中で何度もフィードバックループを回すと言うことができなかった。

なぜAI編集部を作ろうとしたのか

オウンドメディアで記事を継続的に発信するのは、手間がかかる。テーマ選定、調査、執筆、校正、ペルソナによるレビューなどを一人でやり続けることには限界がある。Claude Codeを日常的に使っていると、「この一連のワークフローをAIに任せられないか」と考えるのは自然な流れだった。

ただし、やみくもにAIに任せるだけでは成果物の品質が担保できない。AIに何かを評価させるためには、事前に評価基準を定義しておく必要がある。これは前回の『ローカルLLMでSpec Driven Developmentは、まだ難しかった』での経験とも重なる。人間が最初にゴールを定義し、AIがそれに基づいて実装する というSpec Drivenな構造がなければ、AIの出力物を評価し、修正を行うと言う一連のフィードバックループが成立しない。

`.claude`の構成

今回の .claude のディレクトリ構造は次のとおりである。

.claude
├── agents # 編集長・編集部員・ペルソナ等のエージェント定義
├── docs # オウンドメディアの設計ドキュメント
│ ├── 01_Business-Model
│ │ ├── 01_Concepts
│ │ ├── 02_Design
│ │ ├── 03_Personas
│ │ ├── 04_Value-Proposition-Canvas
│ │ ├── 05_Market-Analysis
│ │ ├── 06_Business-Model-Canvas
│ │ └── 07_RoadMap
│ └── 02_Roles-and-Workflow # 組織構造・編集ルール等
└── skills
 └── article-workflow # 記事作成〜品質保証〜最終承認のワークフロー定義

docs には、人間が定義した事業計画を置く。agents と skills には、その事業計画を元にAIが実装した編集部の構成要素を置く。

人間が定義するもの

まず、Claudeと議論しながら事業計画を立案・策定した。具体的には以下である。

ビジネスモデルの定義: エレベーターピッチを起点に、ペルソナ、バリュープロポジションキャンバス、市場分析などを一通り整備した。
ロールと役割の定義: チーム構成、各メンバーの役割と責任、ワークフロー、編集ルール、ペルソナを定義した。

これらがAIの成果物（今回でいうとオウンドメディアの記事）を評価する拠り所になる。評価基準が曖昧なままエージェントを動かしても、その成果物を正しく評価することはできない。

AIが実装したもの

Claude Codeに対して事業計画等の資料一式を渡したところ、Claude Codeは SKILL と AGENTS を自力で設計・実装した。

SKILLの決定: 記事作成から品質保証・最終承認までの一連のワークフローを article-workflow として定義した。実は、事業計画の中で記事の承認基準や差し戻し基準を明示的に定義していなかったが、私が渡した情報をもとにClaudeが適切に補完した。
AGENTSの決定: 編集長、編集部員、ペルソナ（4名）を定義した。エージェントが達成すべき役割だけでなく、エージェント間でどのような情報を受け渡しするかというインターフェースも、ここで定義されている。

実装自体はMarkdownを書くだけなので、手間は大きくない。ただし今回は、SKILL や AGENTS の分割や、どのように書いた方が効果的なのかはClaudeの方が理解しているだろうと判断し、すべてClaudeに任せた。

問題は、Claudeの成果物のレビューである。「編集部の作業内容」と言う一次情報を持ち合わせていなかったため、Claudeの成果物にハルシネーションが含まれているかどうかの判断が難しかった。今回は常識的な範囲で荒いレビューを行った。未知の分野でAIを使った場合、ハルシネーションを見抜くのは非常に難しいため、AI時代においても一次情報の重要性は変わらないか、より増すものと考えられる。

実際のところ、どうだったか

問題1: 編集長の承認条件が厳しすぎてコンテキストを食い潰した

最初に設定した承認条件はこうだった。

- [ ] ペルソナAI（4名中3名）が「推奨」している
- [ ] 編集長AIの「重要な」指摘事項が0件である
- [ ] ビジネスモデルとの整合性が星4つ以上
- [ ] 読者に与える価値が星4つ以上

良かれと思ってペルソナの属性や性格が被らないように設計した結果、3名全員の「推奨」を取り付けることはほぼ不可能だった。編集長AIの重要指摘事項0件もほとんど達成できない水準だった。これにより、編集者AIが修正 → 編集長AIとペルソナAI4名がレビュー → 指摘に基づいて編集者AIが修正 → …となってコンテキストを食い潰し、article-workflow がセッション内で完走できないケースが続いた。

そこで、承認条件を緩和した。

- [ ] ペルソナAI（4名中2名）が「推奨」している
- [ ] 編集長AIの「重要な」指摘事項が1件以下である
- [ ] ビジネスモデルとの整合性が星4つ以上
- [ ] 読者に与える価値が星4つ以上

ペルソナAIの推奨人数を4名中3名から4名中2名に下げ、また、編集長AIの重要な指摘事項を0件まで落としたことでワークフローが通せるようになった。ローカルLLMであれば seed や temperature 等のパラメータを設定できるので修正指示も一貫する可能性があるが、Claudeの場合はユーザが制御できないようになっており「発散する可能性」を制御できず、修正指示が収束しない可能性を考慮した結果である。つまり、AIの決定性・非決定性は、ワークフロー設計の前提条件になると言うことである。

また、星4つ以上の条件は据え置いた。オウンドメディアと事業戦略の整合性を維持しなければ、記事と記事の間に矛盾が生じるため、ここは緩めなかった。結果として、セッション内で3記事程度は作れるようになった。

エージェントを利用する際、チェックの基準を厳しくしすぎると修正ループが発生し、コンテキストを消耗する。実際の挙動を見ながら調整していく必要がある。

問題2: 執筆された記事が似非マーケターが書いたような内容になった

出力された記事は、如何にもAIが書いたような文体になってしまった。原因は明確だ。編集者AIがどのような文体で執筆すべきかを、最初に定義しなかったからだ。コンテキストの消費量を改善しても依然として大量のコンテキストを使うため、そのうちに面倒になり、この改善には手をつけなかった。

実際に出力された記事

「貯蓄分はないもの」を本気で実感するには、時間差が必要だった

「給料が入ったら、先に貯蓄分を別の口座に移しておく」

これは先取り貯蓄の基本として、よく言われることです。私も何度か試しました。けれど、正直に言うと、しばらくすると元に戻してしまうことが多かったんです。

なぜかというと、銀行口座から別の口座に振り込んでも、どちらも「自分の口座」であることに変わりはなく、心のどこかで「いざとなれば戻せる」と感じていたからだと思います。貯蓄口座に移したはずのお金が、結局「予備財布」のような感覚になっていました。

そんな私が、1年間で50万円を貯められるようになったのは、**自動引き落としの「時間差」**を使うようになってからです。

この記事では、なぜ手動の振込より自動引き落としの方が続きやすかったのか、その心理的な仕組みと、私が実際にやっている方法をお伝えします。あなたにとっての「続く仕組み」を考えるヒントになれば嬉しいです。

学んだこと

構造設計としての有効性: 「事業計画を定義し、その評価基準でAIがAIの成果物を評価する」という構造そのものは成立した。ルールとして明確に定義するものと、その範囲内で目的達成方法をAIに考えさせるという分業は機能した。
一次情報の重要性: 人間とAIの関係を構造設計する際、一次情報をどれだけ知っているかが重要になる。今回の場合、実際の編集部がどのように機能しているかを知らなければ、AIの成果物を厳密にレビューすることは難しい。「知らないことをAIに尋ねるのはよいが、それを評価するのは至難の業」という問題は今回も残った。未知の分野でAIを使った場合、ハルシネーションを見抜くのは非常に難しいため、AI時代においても一次情報の重要性は変わらないか、より増すものと考えられる。
コンテキスト管理の設計: コンテキストの消費量が多いと、改善のフィードバックループが回しにくくなる。今回は CLAUDE.md を活用せずに進めたが、コンテキストの使用効率を高める手段を積極的に取り入れるべきだった。
インデックスの必要性: ZettelkastenにおけるStructured Noteのようなインデックスが、AIのコンテキスト展開を段階的に制御するために重要だと気づいた。AIに何をどこまで読み込ませるかを決めるには、インデックス情報が必要になる。これは前回の『ZettelkastenをRAGの情報源として有効活用するには、ノート間のリンクに「意味ラベル」をつけ、型付きのエッジを持たなければならない』での考察とも合致する。今回利用した SKILL や AGENTS では、このインデックス情報はうまく活用しきれていない。そのため、CLAUDE.md を使うことはこの文脈において有効な手段であると考えている。

次にAIエージェントを立ち上げるときに考えておきたいこと

CLAUDE.md のように、コンテキストの使用効率を高める方法を最初から組み込む。
コンテキスト消費量とフィードバックループの速度はトレードオフになる。いかに効率を高めながらループを回すかが設計の肝になる。
文体や表現スタイルは、事業計画と同じタイミングで定義しておく。後からでは手遅れになる可能性が高い。

まとめ

Claude Codeの SKILL と AGENTS を使ったAI編集部は、形として動かすことはできた。人間が事業計画・役割・ワークフローを定義し、AIが実装するという構造設計は機能した。また、その定義が「AIエージェント間」での拠り所にもなっている様子が見てとれた。
承認条件の設計ミス（?）によるコンテキスト枯渇と、文体定義をしなかったことによる記事の品質低下という、二つの失敗が発生した。いずれも設計段階での考慮不足が原因であり、実装後に気づいても取り返しにくい。
コンテキストの消費量を管理しながらフィードバックループを回す設計が、AIエージェント活用の中心的な課題になる。

ZettelkastenをRAGの情報源として有効活用するには、ノート間のリンクに型付きエッジを持たなければならない

Sun, 22 Feb 2026 00:00:00 +0900

※ この記事は、誤字脱字、表現の冗長さ・曖昧さのチェックのためにClaude Codeを利用している。

TL;DR

本記事で提案する「手動による型付きエッジの付与による運用」は、GraphRAGやNeo4j RAGとは異なり、型付きエッジを手動で付与する。これにより、Zettelkastenの探索を人間の手によって制御し、かつインフラの運用コストを抑えることができる点に差別化要素がある。
ZettelkastenをRAGの情報源として使う場合、ノート間のリンクに型付きエッジを付与しなければ、AIはグラフを無限に辿ってコンテキストが膨張する 。
人間はリンクの意味をノートの文脈から推測できるが、AIにはその判断ができない。これは「人間にとってわかりやすいリンクはAIにとって分からない」という構造的な非対称性である。
データの意味付けを軽視してきた歴史（セマンティックウェブ、ビッグデータ、企業RAG）は、同じ失敗パターンの繰り返しだと解釈できる。
付与する型付きエッジとして supports → / contradicts → / refines → / depends_on → の4種を提案する。
コンテキストが膨張するとOOMによるクラッシュ（MLX）や推論崩壊（llama.cpp）が起きる。これは設計の問題であり、パラメーター調整で解決できるものではない。
実際に計測したところ、型付きエッジによる制約付きグラフ探索（constrained graph traversal）でトークン使用量を約70%削減（556,006 → 163,782トークン）しながら、回答品質をほぼ維持できることを確認した。
ただし、リンクに対する型付きエッジの付与だけが解決策ではない。どこを意味付けし、どこをしないかという全体設計が必要である。

なぜ、ノート間（リンク）の関係を自動抽出ではなく手動で行うのか（はじめに）

GraphRAG¹ や、Neo4j RAGのような手法では、異なる2つのエンティティ間の関係を自動抽出し、型付きエッジを持つグラフを構築する。本記事の提案は、これらと同じくグラフのトラバーサルを意味的に制御するものであるが、設計の前提が異なる。

第一に、ZettelkastenのAI（Claude）による自動操作はすでに試みており、失敗している。AIにノートの作成・メタデータ付与・構造操作を任せた結果、ノイズが混入し、知的生産の基盤としての機能を失った（詳細は『Zettelkastenを機能させ、また形骸化させないために、何でもかんでも入れるべきではない』を参照）。Zettelkastenは自分の思考の蓄積であり、AIによる自動操作とは相容れない。

第二に、インフラコストの問題がある。GraphRAG/Neo4j RAGはグラフDBや埋め込みモデルの常時稼働を前提とし、個人が複数台の端末間で使い回すには重すぎる。本記事の設計は、ObsidianのMarkdownファイルとClaude(MCP)のみで完結し、端末を問わず持ち運べることを条件としている。

つまり、手動による型付きエッジの付与を選んだのは、自動化の限界を実体験した結果と、軽量・ポータブルであるという制約条件の両方によるものである。この選択におけるGraphRAGとの差分は「自動か手動か」だけでなく、「運用環境の重さ」と「Zettelkastenの思想との整合性」にある。

きっかけ

『ローカルLLMでSpec Driven Developmentは、まだ難しかった』という記事を書きながら、「自分のZettelkastenをRAGの情報源として接続すれば、自分の思考を元にした回答が得られるのではないか」という考えが浮かんだ。

ただし、この設計を考えるにあたって、1つの前提がある。過去にAIにノート操作を任せた結果、Zettelkastenがノイズだらけになるという失敗を経験している（『Zettelkastenで管理する情報は何で、どう管理すべきなのか』、『Zettelkastenを機能させ、また形骸化させないために、何でもかんでも入れるべきではない。』）。その経験から、「AIはZettelkastenを読むことはできるが書いてはいけない」という原則をすでに確立している。今回の設計はその原則の上に成り立っている。

しかし、実際に試そうとした瞬間、問題が見えてきた。Zettelkastenのノートはネットワーク型の構造になっており、ノート間には無数のリンクが張り巡らされている。RAGとして使うということは、AIがそのネットワークを辿ってコンテキストを組み立てることになるが、「どのリンクをどこまで辿るか」という制御をどうするかが難しい。

そこで少し考えてみると、問題の本質は「ノート間に型付きエッジが付与されていない」ことだということに気がついた。

ZettelkastenとRAGの相性問題

そもそもRAGとは何かを整理しておく。RAGは、LLMが一般的な訓練データから回答を生成するのではなく、特定のドキュメント群（情報源）を参照しながら回答する仕組みだ。ハルシネーションの影響範囲を限定し、特定ドメインに閉じた回答を得るための構造設計の方法論として使われる。具体的には、Zettelkastenとの組み合わせで期待できるのは、「自分の思考・知識を格納したナレッジベースを、AIが参照しながら回答できるようになること」だ。

ところが、ZettelkastenをそのままRAGとして活用すると問題が起きる。Zettelkastenのノートはそれぞれが他のノートへのリンクを持っており、関連するノートをどんどん参照する構造になっている。AIがネットワークを辿り始めると、関連ノートをすべて読み込もうとしてしまい、コンテキストが際限なく膨張する。

これは設計の問題だ。RAGという文脈においては、どのリンクをどこまで辿るかを制御する「制約付きグラフ探索」がなければ、Zettelkastenは有用な情報源にならない のである。

リンクの「意味」は、人間は理解でき、AIには理解できない

リンクの制約付きグラフ探索の問題は、「このリンクは辿るべきか、辿らなくてよいか」をどう判断するか、である。

人間はノートを読みながら、リンクの意味を文脈から推測できる。「このリンクは根拠として貼ったもの」「このリンクは反論の候補として貼ったもの」「このリンクは前提知識として必要なもの」といった区別を、リンクを貼った瞬間に理解している。

しかし、AIにはそれが分からない。リンクはただの接続であり、その接続が「支持」なのか「反論」なのか「依存」なのかを、ただのリンクから読み解くことはできないのである。

[人間の場合]
ノートA ──リンク──> ノートB
 ↑
 「これは根拠ノートだ」と文脈から判断できる

[AIの場合]
ノートA ──リンク──> ノートB
 ↑
 意味が分からない。全部辿るしかない。

これは「人間にとってわかりやすいリンクはAIにとって分からない」という構造的な非対称性だ。この非対称性を放置したまま「ZettelkastenをRAGに使う」という設計は、機能しない。本質的には『「顧客はわかっていない」を構造的に再解釈する』で議論した内容と同じである。

データの意味付けを後回しにしてきた歴史

この問題は、実は繰り返されてきた「うまくいかない」パターンと同じ構造を持っている。

(1) セマンティックウェブ

Web 2.0の台頭で、膨大な個人メディアがウェブに溢れたとき、ティム・バーナーズ・リーは、RDFやOWLといったメタデータ技術によって情報に意味を付与する「セマンティックウェブ」を提唱した。機械が情報の意味を解釈し、より賢い検索・統合ができるようにするというビジョンだった。

しかし、広くは普及しなかった。既存の膨大なデータにメタデータを付与するコストが、得られるメリットに見合わなかったからだ。現在はベクトル検索との共存という形で、その理念が部分的に受け継がれている。

(2) ビッグデータ

Hadoopなどのデータ分析基盤が「大量のデータに価値がある」という前提で作られた時代、データの意味付けはないがしろにされた。データが何を意味しているのかが分からない状態で分析を行い、期待通りの洞察は得られなかった。

(3) 企業におけるRAG活用

現在も同じパターンが繰り返されている。企業内に存在するExcelやPowerPointといった非定型データをRAGに登録しても、望む回答精度が得られないという課題がある。原因は単純で、ドキュメント内の要素がどのような文脈でどのような意味を持つのかを、AIが理解できないからだ。意味付けのない情報をいくら積み上げても、AIはそれを有効に活用できない。

情報の蓄積に価値があるという幻想と、意味付けのコストを軽視してきた結果が、この繰り返しである と私は考えている。この課題を解決しようとしている企業が多く存在していることからも、今回は同じ繰り返しをしないようにしていると考えられる。

型付きエッジを付与したリンクの提案

この構造的な非対称性を解消するために、リンクに「型付きエッジを付与する」設計を考えた。リンクの種類を以下の4つに分類し、リンクを貼る際に明示的に意味付けを行う。

型	意味	用途
`supports →`	このノートの根拠	主張の根拠を支えるノートへのリンク
`contradicts →`	このノートへの反論	反論・対立する視点へのリンク
`refines →`	このノートの洗練・具体化	上位・下位概念の関係、より詳細な説明へのリンク
`depends_on →`	このノートの前提条件	読む前に理解すべき前提知識へのリンク

実際の記述例はこうなる。

## 主張

ZettelkastenをRAGの情報源として有効活用するには、ノート間のリンクには型付きエッジを付与する必要がある。

- supports → [[人間にとってわかりやすいリンクは、AIにとっては分からない]]
 - context: 人間はリンクの意味を文脈から推測できるが、AIはできない。

- depends_on → [[Zettelkastenのノート間のリンクは型付きエッジによって意味づけしておくことが重要]]
 - context: 型付きエッジがなければ、AIはグラフを無限に探索してしまう。

この設計をすることで、制約付きグラフ探索が可能になる。たとえば「supportsリンクだけを辿る」「depends_onは1ホップまで」といったルールをクエリ時に適用できるようになる。

なお、contradictsリンクが多いノートは、未解決の領域あるいは思考の臨界点を示していることになる。これはAIへの指示の文脈だけでなく、ノートを管理する人間にとっても有用な情報になる。

ただし、この方法には、型付きエッジを後から付与するためのコストが爆発的に増えるという課題がある。

制約付きグラフ探索の効果を計測する

提案している設計の効果を確認するために、実際にトークン使用量を計測した。170ノート・41,370文字・207リンクで構成されたZettelkastenを対象に、「生成AIにおけるRAGの現状と課題」を調査するタスクをClaude Codeに依頼し、制約付きグラフ探索によってどれほど差が出るかを比較した。

条件	サブエージェント実行数	トークン使用量
制約付きグラフ探索なし	12回	556,006トークン
制約付きグラフ探索あり	4回（約67%削減）	163,782トークン（約70%削減）

なしの場合、AIはすべてのリンクを辿るために12のサブエージェントを起動し、55万トークン超を消費した。ありの場合は、型付きエッジをもとに必要なノードに絞り込み、4エージェント・16万トークン強で完了した。

回答品質についても比較した。

回答事項	制約付きグラフ探索あり	制約付きグラフ探索なし
1. RAGの本質的な役割（Vaultが示す再定義）	回答あり	回答あり
2. 実装アーキテクチャの変遷（実体験ベース）	回答あり	回答あり
3. AI Engineer ／ Application Developer の責任境界	回答あり	回答あり
4. ベクトル検索とメタデータの共存	回答なし ²	回答あり
課題1：データ意味付けの困難さ（最重要課題）	回答あり	回答あり
課題2：コンテキスト長の膨張と推論エンジンへの影響	回答あり	回答あり
課題3：リンク意味の不透明性	回答あり	回答あり
課題4：AI／人間の判断境界設計	回答あり	回答あり
課題5：データ更新・削除の複雑性	回答あり	回答あり
課題6：机上設計と実装の乖離	回答あり	回答あり
課題7：歴史的失敗の反復リスク	回答なし ²	回答あり

ありで「ベクトル検索とメタデータの共存」「歴史的失敗の反復リスク」の2項目が未回答となったが、これは型付きエッジによって選ばれたノード群が中心的な問いに絞り込まれた結果であり、カバレッジの欠落ではなく焦点化の結果と解釈している。

トークン使用量を約70%削減しながら回答品質をほぼ維持できたことは、制約付きグラフ探索の有効性を裏付けている。また、データを絞ることでAIが中心的な問いにフォーカスするという副作用も確認できた。コンテキストの膨張は「情報量が多ければ回答の質が上がる」という直感に反し、むしろ回答品質を下げる可能性があることを示唆している。

コンテキスト膨張は実害を生む

これは概念的な話ではなく、『ローカルLLMでSpec Driven Developmentは、まだ難しかった』で身をもって経験した実害でもある。コンテキストが膨張すると、推論エンジンはOOM（Out of Memory）に陥る。その挙動はエンジンによって異なる。

MLX（mlx_lm）: OOMが発生した時点でクラッシュする。これ以降の推論崩壊を防ぐための設計だが、処理が中断される。
llama.cpp: OOM後も ctx_pos / n_past が進み続け、初期化が保証されていないKV Cacheを参照しながら推論を続けてしまう。結果として推論崩壊が起きる。

どちらが良い悪いではなく、設計思想のトレードオフだ。しかし、いずれにしてもコンテキストを膨張させないことが根本的な解決策であり、制約付きグラフ探索はその手段の1つになる。

課題

制約付きグラフ探索は1つの解だが、リンクだけを整備すれば十分というわけではない。ノート内のどの部分がAIにとって「文脈」として有効なのか、何をZettelkastenにおけるメタデータに含めるべきか、ノート自体にどのようなメタデータを持たせるかといった設計の問いは、リンクに対して型付きエッジを付与した後にも残る。型付きエッジの付与は「設計行為」であり、どこを付与し、どこをしないかという全体像を先に決めなければ、部分最適に終わる という考えである。

また、既存の大量のノートに型付きエッジを後から付与するコストも現実的な障壁だ。セマンティックウェブが普及しなかった理由の1つが「既存データへのメタデータ付与コスト」だったこと、GraphRAGが自動で検出を試みていることの2つを考えると、新規ノートから型付きエッジを付け始めて様子を見るスモールスタートが現実的だろうと考えている。

まとめ

ZettelkastenをRAGの情報源として接続するには、ノート間のリンクに型付きエッジが必要である。型付きエッジがなければ、AIがグラフを無限にトラバースしてコンテキストが膨張する。実際の計測では、型付きエッジをもとにした制約付きグラフ探索なしで556,006トークン・12エージェントだったのに対し、ありでは163,782トークン・4エージェントに抑制できた（それぞれ約70%・約67%の削減）。
これはデータに対する型付きエッジの付与を軽視してきた歴史（セマンティックウェブ、ビッグデータ、企業RAG）と同じ構造である。情報の蓄積には価値があるが、意味付けなき蓄積は、AIがそれを有効活用できないという点で、「何を蓄積するか」以上に重要な論点になる。
Zettelkastenのノート間のリンクに意味付けを行うという点においては、supports → / contradicts → / refines → / depends_on → の4種の型付きエッジを提案する。これにより制約付きグラフ探索が可能になると考えている。
コンテキスト膨張はOOMクラッシュや推論崩壊という実害を生む。これはパラメーター調整ではなく、設計で解決すべき問題である。
リンクの型付きエッジは解決策の一部であり、全体の意味付け設計と合わせて考える必要がある。
- リンクの型付きエッジは、双方向リンクに対しては爆発的にコストが大きくなる。片方向だけで十分かどうかも含めて検討する必要がある。

Edge, Darren, Ha Trinh, Newman Cheng, ほか. 「From Local to Global: A Graph RAG Approach to Query-Focused Summarization」. arXiv:2404.16130. 査読前原稿, arXiv, 2025年2月19日. https://doi.org/10.48550/arXiv.2404.16130. ↩︎
制約付きグラフ探索ありで「回答なし」となった項目は、型付きエッジによって選ばれたノート群が中心的な問いに絞り込まれた結果、AIが回答対象として設定しなかったものである。カバレッジの欠落ではなく、焦点化の結果と解釈している。 ↩︎ ↩︎

「顧客はわかっていない」を構造的に再解釈する

Sun, 15 Feb 2026 00:00:00 +0900

TL;DR

「顧客はわかっていない」という感覚は お互いの思考限界がズレている ことを示しているに過ぎない。
顧客は技術的制約を思考限界の外に置き、技術者はビジネス文脈を思考限界の外に置く。この非対称性が衝突を生む。
優れたアーキテクトは、思考限界を動的にずらしながら、顧客・技術者・システムの三者間をコーディネートする。この能力を 構造設計能力 と呼ぶ。
AIとの協働においても、まったく同じ構造が成立する。「AIに何をさせ、何をさせないか」の設計と、「顧客と何を共有し、何を委ねるか」の設計は、同じ問いの別バージョンである。
「顧客はわかっていない」という思考は未熟である。問うべきは「どの思考限界をどこへずらすか」である。

きっかけ

顧客との打ち合わせのあと、「あの人は技術的なことが全くわかっていないから、好き勝手なことを言う」と感じることがある。おそらく多くのエンジニアが、一度はそう思ったことがあるはずだ。

一方で、最近AIを使った開発を進める中で、ある気づきがあった。AIに対して「なんでこんなことをするんだ」「指示通りにやってくれない」と感じる場面が増えてきた。これは、顧客に対して感じることと、構造的にとても似ている。

では、「顧客はわかっていない」という感覚は、本当に正しいのか。逆に顧客の立場から見たらどうなのか。AIとの対比を通じて、この問題を構造的に整理してみたい。

思考限界というフレームワーク

まず、「思考限界」という概念を導入する。

人は誰でも、自分が認識できる範囲に「限界」を持っている。業務を知り尽くしている顧客は、システムがどう実装されているかを必ずしも知らない。逆に、技術者はシステムを構築できるが、その業務がなぜ今の形になっているのか、歴史的・組織的な文脈を把握していないことが多い。

[顧客の思考]
思考限界の内側: 業務知識・経営判断・ユーザー体験
思考限界の外側: 技術的制約・実装コスト・インフラ構造 ← まだ見えていない

[技術者の思考]
思考限界の内側: 技術スタック・実装難易度・パフォーマンス特性
思考限界の外側: 業務フロー・組織の意思決定構造・顧客の顧客の要求 ← まだ見えていない

「顧客はわかっていない」という発言は、技術者の思考限界の内側にある情報を、顧客が持っていないことへの苛立ちである。しかし同時に、顧客の思考限界の内側にある情報を、技術者も持っていない。この非対称性は、どちらかが「わかっていない」という話ではなく、 互いに相手の思考限界の外側に重要な情報を持っている という構造の問題だ。

アーキテクトの役割：思考限界をずらす

では、どうすればよいのか。ここで登場するのが「思考限界を動的にずらす」という設計行為だ。

たとえば、顧客が「膨大なデータを、リアルタイムで全件表示したい」と要求してきたとする。技術者は「100万件を毎秒描画するのは不可能だ」と思う。この時点で衝突が生まれる。しかし、ここで優れたアーキテクトが行うのは、「それは無理です」というのではなく、自身が持つ技術知識をもとに、顧客の思考を分解して考え、思考限界を技術的制約の側に一歩ずらすことである。

[初期状態]
顧客の思考限界の内側: 「全件リアルタイム表示」

↓ アーキテクトが制約を可視化

[目的達成可能な状態]
顧客の思考限界の内側: 「集計ビュー + 閾値超過時のアラート」← 移動させる
顧客の思考限界の外側: 描画コストの詳細（もはや意識不要）

顧客が本当に欲しかったのは「全件表示」ではなく、「意思決定に必要な情報をタイムリーに得ること」だったかもしれない。このように、思考限界をずらすことで、本来の目的に辿り着ける。これが構造設計能力の本質だと考えている。このとき、制約は「できないことの証明」ではなく、 目的へ向かうための設計上の道具 として機能する。制約を設けることでトレードオフが生まれ、そのトレードオフを顧客と共有することで、はじめて合意形成ができる。

AIとの協働に見る、同じ構造

最近、AIを使った開発を進める中でまったく同じ構造を感じるようになった。AIに対して自由さを与えると、出力が発散する。逆に、過度に細かい制約を与えると、AIは制約の範囲でしか動けず、本来解けるはずの問題も解けなくなる。

AIに「思考させる範囲」と「人間が判断すべき範囲」を設計することは、顧客の思考限界と技術者の思考限界の境界を設計することと、構造が同じだ。

Vibe-Codingが崩壊するのも、この制約の設計が欠如しているからだと理解している。RAG、Spec Driven Development、エージェント設計といった手法は、すべてAIの思考限界を設計的に制御する試みであり、「AIに何をわからせ、何は人間が持つか」を明示化するアプローチだ。

対顧客も対AIも、 思考限界の境界を設計することが、問題解決の核心 にあると考えている。

思考限界を動的にずらすことに成功した例

OpenShift：「強制」という制約が自由をもたらす

以前調べたRed Hat OpenShiftが良い事例だと感じた。OpenShiftはGit・OCI・Kubernetesという業界標準を強制することで、開発者の思考限界を「何を使うか」から「どう使うか」にずらしている。

AWS（サービスの集合体）は設計の自由度が高い反面、「何を選ぶか」という判断コストが利用者に集中する。OpenShiftは、その選択の余地をあえて削ることで、350人規模の開発チームでもオンボーディングコストを下げることに成功した。

「強制」という制約が、実は「自由に動ける範囲」を明確にしていた。これはまさに思考限界をずらす設計の実例だ。

Porsche Informatik：「枠」が組織のしがらみを溶かす

Porsche InformatikがプライベートクラウドからOpenShiftに移行した際、6週間で移行を完了し、350人超の開発者が常時利用する環境を実現した。「枠」という制約を設けることで、オープンソースの自由さと、組織の標準化要求という相反する要件を両立している。

これは、顧客（経営層・開発チーム）の思考限界に「標準化された開発プラットフォーム」という概念を移植した結果だと言える。

「構造設計能力」という自己研鑽の方向性

ここまでを整理すると、技術者に求められる能力は次のように言い換えられる。

「自分の思考限界がどこにあるかを把握し、顧客や技術者の思考限界を動的にずらしながら、目的達成へコーディネートする能力」

これを構造設計能力と呼ぶことにしている。技術者の自己研鑽とは、何かの技術を追い続けることによって、「自分の思考限界がどこにあるかを探究し続けること」だと思っている。技術書を読む、新しいフレームワークを触る、顧客の業務フローを深く学ぶ、これらはすべて「自分の思考限界を広げる」行為だ。

ただし、もうひとつ重要なことがある。思考限界を広げるだけでなく、どこに境界を置くかを設計する能力 も同時に必要だということだ。自分が何でも知っていようとすることは、「何でもできるノートパソコン」と同じで、帯に短し、襷に長しになりかねない。何を知っていて、何を知らないのかを具体化し続けることが重要なのではないだろうか（難しい話だが）。

構造設計能力とは、知識の総量ではなく、知識の境界を設計する力 だと今は考えている。

まとめ

「顧客はわかっていない」は、思考限界の非対称性を正確に言い表した言葉ではあるが、それ止まりでは未熟な認識である。
問うべきは「どの思考限界を、どこへ、どうずらすか」であり、この設計行為がアーキテクトの核心的な仕事だと考えている。
AIとの協働においても、この構造はまったく同じだ。「AIに何をわからせるか」の設計と、「顧客に何を共有するか」の設計は、同じ問いの異なる文脈での現れである。
思考限界の自己研鑽は終わりのない旅だが、その方向性は「限界を広げること」と「限界の境界を設計すること」の両輪で成り立つ。

Red Hat OpenShiftのDeveloper SandboxをAWSと比較しながら触ってみた

Sun, 15 Feb 2026 00:00:00 +0900

TL;DR

AWS は多数のサービスを組み合わせて使う Service の集合体であり、自由度が高い反面、設計・統合の責任は利用者側にある。
Red Hat OpenShift は業界標準（Git / OCI / Kubernetes）を強制する Platform as a Product として設計されており、最初から統合された開発・運用体験を提供することを目的としている。
Developer Sandboxでは以下の点から、迷わず進める体験が強く印象に残った。
- Gitリポジトリ指定だけでビルド〜デプロイまで完結する。
- Podログ・ターミナル・リソース使用量が1画面で確認可能である。
- AIアシスタント Lightspeed により学習コストが低減している。
Developer Sandboxの基盤はAWS EC2上で動作しているが、実体はROSA(Redhat OpenShift Service on AWS) 上のOpenShiftであり、マルチクラウドで動作することをログレベルで体感した。
閉域網要件やオンプレ併用が求められる企業システムでは、OpenShiftのマルチクラウド設計が大きな強みになる。また、上記の理由から組織の習熟度やスキルに応じて、選択肢の幅を広げていることにもつながる。
結論として、AWSは“自由を最大化するプラットフォーム”、OpenShiftは“標準化で速度と再現性を出すプロダクト”であり、優劣ではなく設計思想の違いが現れているのだと実感した。

きっかけ

普段の仕事では、AWSを使う機会が多い。ECS/Fargate、CodeBuild、Lambdaなど、サービスを組み合わせて作ること、その考え方には慣れてきたが、一方でその「組み合わせる責任」を、常にアーキテクトが負っていることは感じていた。「追いかけ続けるのは大変だ」と思う今日この頃です。

そこで、とあることがきっかけとなりRed Hat OpenShiftが Platform as a Product という考え方で設計されていると知り、それがAWSとどう違うのかを自分の手で確かめてみたくなり、無料で使える Developer Sandbox があると知り、週末を使って触ってみた。

Platform as a Service vs Platform as a Product

AWSを一言で表すとすれば サービスの集合体 だろう。EC2、RDS、Lambda、ECSなど、数百に及ぶサービスが並んでおり、利用者はその中から自分のユースケースに合ったものを選び、組み合わせて使う。自由度は極めて高い。

しかし裏を返せば、どのサービスをどう組み合わせるかの設計責任はすべて利用者にある ということだ。CI/CDパイプラインを1本作るにも、CodeCommit → CodeBuild → Amazon ECR → Amazon ECSという工程を整え、IAMロール、セキュリティグループなど、自分で判断、設計しなければならない。熟練者には自由だが、習熟の浅いエンジニアには高い壁になる。

それに対して、OpenShiftのアプローチは対照的だ。Git、OCI（ Open Container Initiative、コンテナ規格）、Kubernetesといった業界標準を強制することで、開発者が最初からある一定の土台の上に立てる設計になっている。何でもできる、のではなく、標準という枠に沿ってできる、というわけだ。

この「強制」はベンダーロックインの回避にも繋がっている。OpenShiftはAWS/Azure/オンプレミス等で動作する。アプリケーションコードはどの環境でも同じように動く。AWSのマネージドサービスに依存した設計と違い、インフラの切り替えコストが低い。

Developer Sandboxで試したこと

Lightspeedとの統合

OpenShiftはコンソールにAIアシスタント Lightspeed が統合されている。試したのは、Podが起動していない状態でどうアクセスすればよいかを尋ねる場面だ。

私: The pods are not running so I cannot connect via ssh. If the pods are running, I can connect to these pods via console from anywhere?

Lightspeed: Yes, if the pods are running, you can connect to them using the OpenShift console or CLI from anywhere, provided you have network access to the cluster and the necessary permissions. Here’s how you can do it:

OpenShift Console: Access the OpenShift web console using your browser. Navigate to the specific project and pod, and use the terminal feature to open a shell inside the pod.

OpenShift CLI: Use the oc command-line tool to interact with the pods. You can start a remote shell session with the following command: …

KubernetesやOpenShiftの概念を前提とした回答が返ってくるため、独自ドキュメントを読み漁る前に「なぜこうなっているのか」の文脈を掴める。経験の浅いエンジニアでも自己解決までの距離が縮まる、という点でこの統合は意味が大きいと思う。

Gitからのデプロイ

まず試したのが、Gitリポジトリからのデプロイである。Developer Sandboxの画面からGitリポジトリのURLを指定するだけで、コンテナのビルドからPod・Serviceの生成まで自動で行われる。

GitHubのリポジトリに限らず、自前のGitサーバ、CodeCommitなど、名前解決できる場所にあれば何でも使える。

AWSで同じことをしようとすると、CodeCommit（またはGitHubとの連携）→ CodeBuild（ビルド設定・buildspec.yml）→ Amazon ECR（イメージ登録）→ Amazon ECS（タスク定義・サービス設定）という順を踏まなければならない。それぞれのサービスの設定と試行錯誤で1日潰れることも珍しくない。

パイプラインは難しい と感じる習熟レベルの人でも、OpenShiftなら最初のデプロイまで数分で到達できる。この体験の差は大きい。

ログとターミナルの統合

デプロイ後、ログをコンソールから確認してみた。PodのログはOpenShift ConsoleからPod単位でリアルタイムにストリーミングされる。

ログを眺めていると、気になる行が目に入った。

Successfully assigned ***-dev/code-with-quarkus-665467cf97-9rcdb to ip-10-0-86-229.ec2.internal

ec2.internal が示すように、Developer Sandbox自体のバックエンドはAWS EC2上で動いている。実際には、Red HatがAWS上でマネージド提供するROSA（Red Hat OpenShift Service on AWS）を基盤としており、その上にOpenShiftクラスタが構成されている。このログを通じて、OpenShiftが特定のインフラに依存しないプラットフォームであることを実感した。

AWSでアプリケーションのログを確認しようとすると、CloudWatch Logs → ロググループ → ログストリームという階層を辿らなければならず、慣れていないとどこを見れば良いか迷う。OpenShiftはPodを選べばそのままログが見える。この一体感は確かに違う。

Podへの接続は、コンソールから直接できる。また、OpenShift CLI（oc）を使えば、普段使っているターミナルから一時認証情報を使ってPodにアクセスできる。

リソースの可視化

CPU・メモリ・ファイルシステムの使用状況が時系列グラフでコンソールに表示される。CloudWatchでこれを実現しようとすると、CloudWatch Agentをインストールする必要がある。OpenShiftはデプロイ直後からリソースの状況が一画面で見える。

AWSとの比較: 閉域網要件

企業システムでよく要件に上がるのが「インターネットに通信を出したくない」という閉域網の要求だ。

AWSで閉域運用を実現しようとすると、VPC Endpoint（各サービスごとに作成が必要）、Route53 Private Hosted Zone（DNS解決の制御）などを組み合わせる必要がある。設定が複雑になるうえ、VPC Endpointによって課金ポイントも増える。予算の制約とのバランスをとることも難しい。

OpenShiftはインフラを抽象化しているため、完全閉域が必要ならオンプレミス、柔軟性が必要ならクラウドという配置場所の変更が、アプリケーションの変更なしに実現できる。組織のクラウド習熟度や用途に応じて、オンプレとクラウドを使い分ける選択肢があり、さらにそれらの移動が比較的容易であると言える。

セキュリティ要件の厳しい業界（金融・公共）への提案を考えると、この柔軟性は大きな差別化点になる。

導入事例から読み解く

Porsche Informatik：6週間でのレガシー移行

市場への投入スピードを競うPorsche Informatikは、プライベートクラウドで動作していたアプリケーションをOpenShiftへ移行した。所要期間は6週間。現在は350人を超える開発者が常時利用しており、Market-inまでの時間を90%向上させたという。

スピードで語られることの多い事例だが、「350人が常時利用」という点も注目に値する。OpenShiftが「強制」する標準的な作法が、大規模な開発組織でのオンボーディングコストを下げていると考えられる。

参考: Porsche Informatik、Red Hat OpenShift でユーザーエクスペリエンスを促進

JRA（日本中央競馬会）：5000万PVの動的スケーリング

JRAは土日に1日に5,000万PV、平日はそれ以下という極端なトラフィックの波を抱えている。従来のプライベートクラウド基盤で静的にリソースを確保するのではなく、OpenShiftへ移行してHPA（Horizontal Pod Autoscaler）によるPod数の動的な増減で対応しているようだ。

成果として以下のようなものが得られているようである。

脆弱性対応の頻度が6ヶ月→2ヶ月に短縮
本番リリース作業が5時間→1時間に短縮

脆弱性対応の短縮はローリングアップデートによるOpenShiftコントロールプレーンの更新速度と、DevOpsによるアプリケーション側の対応高速化の両方が効いていると考えられる。本番リリース作業の短縮はBlue/Greenデプロイメントが機能していると思われる。現場の開発者/運用者にとっては非常に大きな改善であると言える。

なお、スケーリング戦略としてHPAを使っているのは合理的だと感じた。もしVPA（Vertical Pod Autoscaler）を使うとPodの再起動が必要になり、複雑さが増す。リクエスト数の波に対してはPod数で柔軟に対応するHPAの方が向いている。

参考: 日本中央競馬会が公式ウェブサイトのプラットフォームにRed Hat OpenShiftを採用

まとめ

Developer Sandboxを触って感じたのは、自由度と使いやすさのトレードオフに対するRed Hatなりの答えだ。

AWSは設計の自由度が高い反面、その自由を使いこなすための学習コストと、組み合わせの責任を利用者が負う。対するOpenShiftは、標準を強制することで、誰が使っても一定の品質と速度でデプロイ・運用できる土台を提供している。

Gitからのデプロイ、ログとターミナルの一体化、Lightspeedとの統合など、これらはどれも「開発者がやりたいことに集中できる環境」を実現するための設計であり、サービスを繋ぎ合わせて仕組みを作らせようとするAWSとは出発点が違う。（念のため、どちらが良い悪いではなく、思想の違いということです）

閉域網要件や既存のオンプレ資産との共存が求められる企業システムにこそ、このプロダクトの価値が発揮される場面がありそうだと感じた。

ローカルLLMのtemperatureとseedが生成品質に与える影響と「推論言語」の関係

Sun, 15 Feb 2026 00:00:00 +0900

TL; DR

ローカルLLM（Deepseek R1 0528 Qwen3 8B）で temperature と seed が生成結果に与える影響を実験した
seed を固定しないと temperature = 0 でも出力は再現されない（厳密に言えば量子化の結果として結果が揺れる可能性はある）。Geminiによると、GPU演算や並列処理の関係でも推論結果がズレることがあるとのこと。
コード生成（FizzBuzz）のように結果を収束させたい場合には、以下のようにすると良いと思われる。
- temperature = 0 + seed 固定が最も安定
- temperature を上げると、細部にバグが混入リスクが増える
俳句生成のような創作系タスクでは、以下のようにすると良いと思われる。
- temperature = 0 だと中国語で推論され、日本語俳句の形式（5-7-5・季語）が崩壊しやすい
- temperature = 0.3 が最もバランスが良いと感じられた。それでもモデルの訓練データの関係から日本語俳句の形式は取られない。
- temperature = 1.2 では出力が説明的、崩壊しがちになる。
推論（思考）に使われる言語が出力品質を大きく左右する
- 日本語プロンプトでも、日本語で推論されるとは限らない。
- 推論言語は訓練データの偏り＋seed＋temperatureの組み合わせで決まる。
repeat-penalty = 1.0 では無限ループが発生することがある
- 無限ループが発生した場合には、repeat-penalty = 1.2 程度まで上げると良い。
結論としては、temperature だけを調整しても不十分で、 seed と推論言語を含めて設計しないと安定した品質は得られない。ローカルLLMのパラメータ調整は「おまじない」ではなく、モデル内部の挙動を理解した設計行為である。

きっかけ

前回の記事でローカルLLMのクラッシュと推論崩壊に苦しめられた。Context Lengthの設定を見直すとともに、「そもそもパラメータをどう設定すれば望ましい生成結果が得られるのか」という疑問が湧いた。

ここでは、top-pやContext Lengthといったパラメータよりも生成結果の変化に直結するtemperatureとseedに絞ってパラメータを動かし、それが生成結果にどのように影響を与えるのかを調べてみた。

実験環境

機材等

MacBook M3 24GB RAM
LM Studio バージョン0.4.2 (Build 2) / Metal llama.cpp v2.1.0
モデル: Deepseek R1 0528 Qwen3 8B（GGUF、GPU Full Off-Load）

パラメータ

temperatureのみを変化させ、その他は以下の通り固定した。

パラメータ	値
Context Length	8192
GPU Off-Load	36（Full Off-Load）
repeat-penalty	1.0
top-p	0.8
seed	42（固定）

なお最初に気がついたこととして、 seedを固定しないとtemperature　=　0でも結果が揺れる 。temperature = 0にも関わらず生成結果が揺れたのを見て、モデル内の確率分布が seed によって規定されるということを知った。

モデル内の確率分布を決定するのが seed であり、今回使用したモデルの初期値はランダム値であった。temperature はトークン間のスコア分布の大小を決めるものである。seed が固定され temperature = 0 の場合、複数回処理を繰り返しても、推論過程も含めて完全に同一の結果が得られる（量子化による微妙な差が生じる可能性はあるが、ほぼ無視できるレベルである）。

実験①：　プログラムコードを生成する（FizzBuzz）

プロンプト

あなたは以下のMain.javaを読んでいます。
適切な形でfizzbuzz関数を実装してください。
不必要に思考せず、簡潔に答えてください。

class FizzBuzz {
 public static void main(String[] args) {
 for (int i = 0; i < 50; i++) {
 fizzbuzz(i)
 }
 }

 private void fizzbuzz(int i) {
 // TODO: Implement here
 // Spec:
 // - This function print:
 // "i: fizz" if i is multiple of 3
 // "i: buzz" if i is multiple of 5
 // "i: fizzbuzz" if i is multiple of both 3 and 5
 // "i: -" if others
 // - Each line should be ended with break line.
 }
}

temperature = 0 （決定的）

3回とも完全に同一のコードが生成された。推論は英語で行われ、安定して正しい実装が行われた。

private static void fizzbuzz(int i) {
 if (i % 15 == 0) {
 System.out.println(i + ": fizzbuzz");
 } else if (i % 3 == 0) {
 System.out.println(i + ": fizz");
 } else if (i % 5 == 0) {
 System.out.println(i + ": buzz");
 } else {
 System.out.println(i + ": -");
 }
}

temperature = 0.3 （やや多様）

バグが混入した。iを変数ではなく文字列リテラルとして出力してしまっている（1回目・3回目）。

// 1回目・3回目（バグあり）
private void fizzbuzz(int i) {
 if (i % 15 == 0) {
 System.out.println("i: fizzbuzz"); // ← iではなく"i"になっている
 } else if (i % 3 == 0) {
 System.out.println("i: fizz");
 } ...
}

2回目はバグなしで temperature=0 の時と同じ実装が得られた。ロジック自体は3回とも同じで、temperature = 0.3ではトークン間の分布差が小さくなる為に、実装方針に大きな差は生まれなかったが、細部の精度が落ちる場合があることが分かった。

temperature=1.2（多様）

FizzBuzzの条件判定がif i % 15 == 0からif i % 3 == 0 && i % 5 == 0に変化するなど、より多様な実装が出た。引き続きバグを含む回答も混じる。

3回目には 推論過程が初めて日本語になった（1・2回目は英語）。推論/思考の言語もまた、トークン選択の確率によって決まる。また、今回は fizzbuzz() メソッドのみ出力し、 main() が出力されないケースも発生した。

// 3回目（temperature=1.2、推論が日本語になった回）
private static void fizzbuzz(int i) {
 if (i % 15 == 0) {
 System.out.println(i + ": fizzbuzz");
 } else if (i % 3 == 0) {
 System.out.println(i + ": fizz");
 } else if (i % 5 == 0) {
 System.out.println(i + ": buzz");
 } else {
 System.out.println(i + ": -");
 }
}

なお、全ての試行を通じて、初心者がやりがちな「if i % 3 == 0を先に評価してしまうミス」は一度も発生しなかった。

コード生成の観察まとめ

temperature を上げても収束型タスク（コード）では大きな傾向の変化はないが、細部にバグが混入するリスクがある
temperature=1.2 で、推論言語が英語→日本語に切り替わることがある
コードのように 正解を決めたい タスクにはtemperature=0固定が安全

実験②：俳句を生成する

以下のプロンプトを使った。

2月の季語を使いながら俳句を生成してください。
- 形式は5-7-5
- 冬の終わりの静寂さとの別れを彷彿させる俳句
- 破調（5-7-5の崩れ）も積極的に使用 // ← わざと揺れさせるように
- 対比する句を3句作成（例：朝・昼・夜） // ← わざと揺れさせるように

temperature = 0 （決定的）

推論が 中国語 で行われた。3回とも完全に同一の結果で、推論言語も変わらなかった。

（推論の一部）

嗯，用户想要用2月的季语创作俳句，主题是冬末的静寂感和离别氛围，
还特别要求使用破调和对毎句。这个需求挺有意思的，看来用户对俳句有一定了解...

出力された俳句（全3回共通）：

句1: 朝の雪が舞い散る窓 静かに静かに静かだ冬の終わりを告げるこの季節の美しさは憂いを帯びて

句2: 午後の枯枝が揺れる風 冷たく冷たく冷たい待ち続ける季語たちのささやく別れの言葉

句3: 夜の灯りが揺れる窓 孤独に孤独に孤独だ季節は去りゆくが心はまだ冬の静寂に囚われて

俳句として成立していない（5-7-5どころか形式が別物）上、説明的かつ繰り返しが使われている。中国語で推論したことで、日本語俳句の形式制約が守られなかったと考えられる。

temperature = 0.3 （やや多様）

引き続き推論は中国語で行われた。ただし temperature=0 と同一の推論過程ではなく、出力にも多様性が出た。

1回目はプロンプトに答えていない句が出た。一部、回答に中国語文字（阴り）が含まれる。

句例1:

窓の外の雪が融け出す

季語: 雪が融け出す (雪解けの始まり)

イメージ: 冬の終わり、雪が消え始める静寂と、その過程での期待や寂しさを表現。

句例2:

さくらんぼの花が咲き出す

季語: さくらんぼの花 (2月の梅の花、暁花)

イメージ: 別れを彷彿させる、美しいが儚い花の開く様子。破調（5-7-5）ではありますが、季語と題意を満たしています。

句例3:

日は阴り少なくなった

季語: 日は阴り少なくなった (日陰が減った、日照時間が長くなった)

イメージ: 冬の厳しさが和らぎ、春に向かう静かな変化。別れの訪れを暗示。

2回目は1回目と大きく変わり、異なる季語・構成になった（コード実験と比べると、自然言語の方がtemperatureの変化に対して出力の揺れが大きい）。

季語：立春

句：立春の木枯らぎ / さよなら雪 / 窓の外で待ち

説明： 「立春」が季語、「木枯らぎ」（枯れ木）が2月の風景を表す。破調の6-7-5で始まり、冬の終わりの静寂と去りゆく雪、窓の外で待ち続ける情景を描く。

季語：梅雨

句：梅雨の朝露 / かすかに春の匂い / うっかり吸い込む

説明： 「梅雨」が季語、「朝露」が2月の季語風景。破調の5-7-5で、ほのかな春の匂いを帯びた湿った空気を、つい意識せずに吸い込む無邪気さを表現。

季語：雫

句：雫の花蕾 / 未だ届けられぬ手紙 / 春待ちの季語

説明： 「雫」（しぶき、滴）が季語、「花蕾」（芽）が春の訪れを象徴。破調の5-5-5で、まだ届いていない別れの手紙と、待ち続ける季語の重ね合わせを表現。

3回目は repeat-penalty = 1.0の影響で無限ループに陥り、俳句を最後まで生成できなかった 。

temperature = 1.2 （多様）

1回目は、俳句として成立していないものの説明的な言葉は控えられている点に注目した。中国語で推論されていた。

朝霜降る春待ちかな

雪降り山の間は静かに

夜の季語に山は青し

2回目は 日本語で推論 した。temperatureの値により、推論/思考に使う言語として日本語が選択されたと考えられる。ただし、俳句としては成立していない。

（2回目の推論）

まず、ユーザーのクエリを理解します。ユーザーは2月の季語を使って俳句を作成してほしいと要請しています。

二月寒風、枯れ木そよぐ静かに、別れの訪れ
梅雨明けの青空、雪の跡が消え行く、心のほろび
古池の水面結晶、冬が終りを告げる、孤独な夜
6-7-5の句：風雪舞う空庭、往く者もなしの別れ、季節の幕下り
7-5-5の句：灯す街路灯一筋、静寂が二重に深まる、時の流れを想う
5-8-5の句：窓の外白い霧、待ち続ける影たちが重なる、冬の最後の夢

3回目は、やや説明的な言葉が目立つ。こちらも中国語で推論/思考していた。

1. 朝： 正月に雪かすがり、君はもう去りぬ
2. 昼： 窓辺、霜枯らむ、そよ風立ち込める
3. 夜： 長閑、月光の下、さよならの言葉響く

俳句生成のまとめ

temperature = 0では、Deepseekは中国語で推論し、日本語俳句の形式制約が守られない。トレーニングのほとんどが中国語によって行われていることに起因すると考えられる。
temperature = 0.3では、推論過程の変化が生まれ、出力の質も変わる。個人的には最もバランスの良い生成をしていると感じた。
temperature = 1.2では、思考の幅が広がってしまい、俳句として成立しなくなり、また説明的な言葉が目立つようになる。一言で言えば回答が崩壊する。
repeat-penalty=1.0だと、無限ループリスクがある。

加えて、見落としがちな変数としての推論言語

最も印象的だったのは、 推論（思考）に用いられる言語が出力の質を大きく左右する という点だ。

Deepseekは大量の中国語・英語のデータで訓練されていると想定する。seed 固定、temperature = 0 という決定的な状態では、推論言語として中国を選択しやすくなるのはその為であると考える。中国語で俳句の作り方を「考える」と、古典詩の知識がベースになり、日本語の俳句の5-7-5・季語という制約へのアクセスが弱くなる。

一方、プログラムコードは、プログラム作成用途で英語で訓練されたモデルを使うと良い。これは、プログラムコードの訓練データ（ドキュメント、マニュアル、エラーログなど）が英語圏に集中していることと対応している。

また、「日本語でプロンプトを書いたから日本語で推論される」わけではない。推論言語はモデルの訓練データの偏りと、 seed 、 temperature の組み合わせによって決まる。

パラメータ設定の指針

今回の実験から導いた実践的な指針をまとめる。

結果を収束させたい場合（プログラミング）

英語圏で、プログラミング用途に訓練されたモデルを選ぶ
seed を固定する
temperature は0に設定する

多様性を出したい場合（創作系タスク）

そのタスクの言語に強いモデルを選ぶ（日本語の俳句なら日本語で訓練されているモデル）
seed は固定する
temperature は0.3程度にする。1.2まで広げてしまうと回答品質は落ちるように見える。
repeat-penalty は1.2程度に設定する（無限ループ防止）
応答長に上限を設けて完走不可リスクを軽減する

まとめ

temperature だけで生成結果を制御しようとするのは難しい。seed も一緒に固定しなければ、同じ temperature = 0 でも実行ごとに結果がばらつく。また、推論に使われる思考言語という変数が、特に自然言語生成の品質に大きく影響することが分かった。

とはいえ、temperature = 0が「常に最良」というわけでもない。コードのような収束型タスクには適しているが、創作系では推論言語が適切でなければ形式制約を無視した出力が返ってくる。

ローカルLLMで品質の高い出力を安定して得るには、モデルの訓練言語・タスクの特性・パラメータの組み合わせを一体として設計する必要がある。パラメータチューニングは「おまじない」ではなく、モデルの内部動作への理解を伴って初めて機能するものだと感じた。

今後の課題

日本語に特化したモデルを使い、本当に俳句をきちんと作り上げることができるのかを検証する。
Deepseekで検討した傾向と同様の結果になるのかを確認する。

ローカルLLMでSpec Driven Developmentは、まだ難しかった

Sat, 14 Feb 2026 00:00:00 +0900

TL; DR

ローカルLLM（LM Studio） + AiderでSpec Driven Development（SDD）を試したが、実用には至らなかった
14Bクラスのモデルでは推論性能が不足し、以下のような問題が頻発した。
- 仕様外のファイル生成
- 過剰修正
- 英語/日本語のコード再生成ループ
一方で、より大きなモデルはメモリ制約（MacBook M3 / 24GB）で動かせない
Deepseek系モデルでは、エンジンの設計上のトレードオフに直面した
- MLX：OOMで即クラッシュ
- llama.cpp：OOM後も動き続けるが推論崩壊が発生
推論性能が低いほど、開発者側に高度な仕様記述スキルが要求される
- ローカルLLMでSDDをするには、SDDが不要なほどの知識と熟練が必要
Context Lengthは後から調整するものではなく、KV Cacheとメモリ量を踏まえた事前の設計判断が必須
ローカルLLMは「クラウドLLMの安価な代替」ではなく、オンプレAI基盤としての設計・運用能力を要求される計算基盤
結論としては、現時点の個人環境では、ローカルLLMで実用的なSDDを行うのは現実的ではない。

きっかけ

Spec Driven Development （SDD）を試してみたいと思っていた。ClaudeなどのクラウドLLMを使えばそのまま実践できるが、実験を何度も繰り返すにはコストが気になる。そこで「LM StudioのOpenAI互換APIにAiderのバックエンドを向ければ、ローカルでSDDを動かせるのでは」と考えた。

ちなみにここでいうSDDとは、AIに対して厳密な仕様書（プロンプト）を与えることで実装を自律的に行わせる開発手法を指している。

環境

モデル: qwen/qwen2.5-coder-14b
MacBook M3（24GB RAM）
LM Studioバージョン0.4.2+2
aider 0.82.3

試行の記録

Qwenでの失敗：14Bの壁

Aiderを立ち上げ、Kotlinアプリの仕様書を渡して実装を指示してみた。

仕様書

- Objective

Users will be motivated to streak their good habits using this app.

- Function

This app provides users the following functions:

User can:

FUNC-1. Create, update and delete habits
FUNC-2. Track their progress. The definition of "progress" is "how long the user keep doing" not "how many times the user did a week."
FUNC-3. Even the habits are deleted, user can track their progress.

User cannot:

1. Track the progress by recording "how many times they did". The app has status only "done, or not done."

- MVP
 First, FUNC-1 should be implemented. Other functions are not required now.

- Architecture

This is Android app. The project setting is as follows:

- **Name**: Habit Tracker
- **Package name**: net.sonohen.app.habittracker
- **Save location**: /Users/sonohen/code/net.sonohen.app.habittracker
- **Language**: Kotlin
- **Minimum SDK**: API 24 ("Nougat"; Android 7.0)
- **Build configuration language**: Kotlin DSL (build.gradle.kts) [Recommended]

* Implementation Constraints

- Implement ONLY what is specified in this document
- Do NOT add features beyond MVP scope
- Do NOT modify UI text without explicit instruction
- Do NOT add "nice to have" improvements

* Source Structure
 `~/code/net.sonohen.app.habittracker/app/src/main/java/net/sonohen/app/habittracker`

* Testing Source (For unit test)
 `~/code/net.sonohen.app.habittracker/app/src/test/java/net/sonohen/app/habittracker`

* Testing Source (For testing on Android device or emulator)
 `~/code/net.sonohen.app.habittracker/app/src/main/java/net/sonohen/app/habittracker`

すると、3つの問題が表面化した。

意図しない場所へのファイル作成: 仕様書に書いていないディレクトリにソースファイルが生成される。（パスを指定しているにもかかわらず）
過剰修正: 画面に表示されるメッセージについて、「カジュアルにせよ」という指示をしていないにもかかわらず「ユーザはカジュアルにせよと指示している」と言って聞かず、延々と修正を繰り返す。
英語/日本語ループ: —英語で推論/思考を行なってコードを生成した後、日本語でも（英語時と）まったく同じコードを再生成するループに入ってしまう。

根本的な問題は2点に整理できる。

モデルの制約: 14B程度ではタスクを分解して自律的に動作するには推論性能が不足している。
メモリの制約: 14B超のモデルはMacBook M3（24GB RAM）では動かせない。長いコンテキストを保持しつつ、Android StudioやChromeなどでメモリを消費していると、スワップ回避や量子化率を下げて精度を確保することを考慮しても、実用的には48GB以上のメモリが欲しくなる。

Deepseekへの乗り換えとクラッシュ・推論崩壊

14Bの壁を越えるべく、M3 MacBookでもGPUに完全オフロードできる Deepseek R1 0528 Qwen3 8B に切り替えた。

まずmlx_lmエンジン（MLXバックエンド）で試したところ、以下のエラーでクラッシュした。

litellm.APIConnectionError: APIConnectionError: OpenAIException - Error in iterating prediction stream: Exception:
Encountered fatal exception in the backend scheduler: Traceback (most recent call last):
 File ".../mlx_engine/model_kit/batched_model_kit.py", line 216, in _generate_with_exception_handling
 self._generate()
 File ".../mlx_engine/model_kit/batched_model_kit.py", line 338, in _generate
 responses = batch_generator.next()
 ^^^^^^^^^^^^^^^^^^^^^^
 File ".../mlx_lm/generate.py", line 1266, in next
 return self._next()

MLXはOut of Memory（OOM）により物理メモリの割り当てに失敗すると、以降の推論崩壊を防止するために処理を停止する設計になっている。そのためOOMが発生した瞬間にクラッシュする。今回の場合、生成されたトークンが11,000を超えたあたりでクラッシュしている。

次にクラッシュを回避するため、DeepseekをMLXフォーマットからGGUFフォーマットに変更し、llama.cppバックエンドに切り替えたところ、11,000トークンを超えても回答を生成するようにはなった。

しかし、今度は 推論崩壊 が発生した。llama-cliはOOMが発生してもctx_pos / n_pastが進み続ける設計であり、初期化が保証されていないKV Cacheを文脈として使い続けるため、推論が崩壊しながら処理を続けてしまうのだ。

これは、両者の良し悪しではなく、設計思想によるトレードオフである。

失敗から学んだこと

推論性能と開発者スキルはトレードオフになる

SDDは「仕様書を書けばAIがコードを生成する」ものだが、AIの推論性能が低い場合は開発者の仕様記述能力への要求が高まる。推論性能に期待できない環境では、Javaならソースコードの配置先、Unit Testの書き方、UIのレイアウト方針、データベース設計など、これらすべてを厳密な仕様として事前に記述する責任が開発者に生まれる。

逆説的だが、 ローカルLLMでSDDを実践するには、SDDを必要としないほどのスキルが求められる ことになる。

過剰修正とループへの対処

モデルのタスク分解能力が低いと「要求していない箇所まで修正する」「同じコードを別言語（英語の次に日本語で推論・思考が行われるなど）のプロンプトで再生成するループに入る」という問題行動が発生しやすい。対策として、1つの指示を可能な限り小さく・明確に絞り込み、1ファイル・1関数単位でやり取りするのが現実的だと感じた。

Context LengthはKV Cacheとメモリの設計判断

Context Lengthは単に大きく設定すれば良いというものではない。Context Lengthが要求するKV Cacheのサイズは、モデルのアーキテクチャと量子化ビット数によって決まる動的メモリ量だ。OOMが発生すると、エンジンによってはクラッシュで止まり（MLX）、あるいは推論崩壊しながら動き続ける（llama.cpp）。

Context Lengthの設定は、モデルとハードウェアのメモリ量を踏まえた設計判断として事前に確定させる必要がある¹。

ローカルLLMを使うには、オンプレミスのインフラ設計で求められるような設計を開発者に要求する

今回最も印象に残ったのは、「ローカルLLMはクラウドLLMの手軽な代替ではない」という認識だ。ローカルLLMはマシンスペックさえあれば手軽に試せるという文脈で紹介されがちであるが、実際に使おうと思うとかなり難しい。しかし、クラウドで提供される生成AIであればインフラのことを意識しなくて済む。しかしローカルLLMでは、モデルの選定・量子化方式・推論エンジンの選択・Context Lengthとメモリの関係など、これらをオンプレミス環境のサーバ運用と同等の感覚で設計する必要がある。

仕事では「セキュリティを要求する顧客にはオンプレの生成AIを提供すべきではないか」という議論が時たま起こるが、決してそんな単純な判断軸ではないと体感した。

まとめ

ローカルLLM（LM Studio + Aider）でSpec Driven Developmentを試みたが、モデルの推論性能とハードウェアの制約という2つの壁に阻まれ、実用的なSDDには至らなかった。

主な学びをまとめると以下の通りになる。

推論性能が低いほど、開発者の仕様記述スキルへの要求が高まる（推論性能と人間スキルのトレードオフ）
過剰修正・言語ループを防ぐには指示を細かく分割する
Context LengthはKV Cacheとメモリの設計判断であり、後から調整するものではない
ローカルLLMはオンプレ運用と同等の設計思想が必要な計算基盤である

今後の展望としては、 Spec Kit で仕様・機能を洗い出し、 Aider は実装フェーズのみに限定するという役割分担も検討したい。また、クラッシュと推論崩壊を防ぐために各種パラメータの設定と格闘した記録は、次の記事に書いている。

とすると、ClaudeやGeminiという多数がアクセスするLLMのパラメータや基盤設計がどうなっているのかは非常に気になるところである。 ↩︎

Slackと連携するチャットボットをOpenSearch + Bedrockで構築するまでの設計変遷と気づき

Sun, 08 Feb 2026 00:00:00 +0900

きっかけ

社内で周囲の人がGPU搭載のマシンでLLMを動かしているのを見ていた。それ自体は良いのだが、「今時サーバレスだろjk」という思いもあり（当時Chromebook使ってましたし）、オンプレ前提の風潮に違和感を覚えていた。

実用性は度外視して、SLM（Small Language Model）であればAWS Lambdaの制約範囲内¹で動作するのではないかと思った。ただ動かすだけでは面白くないので、当時使っていた「ひとりSlack」から使えるチャットボットを作ることにした。Slack Incoming Web-hook APIを使えば、複雑な認証なしで統合できることも決め手になった。

但し書き

この記事は、2024年頃に検証した時のメモをブログに書き起こしたものです。一部、アップデートがかかっている箇所もあります。

試行錯誤の記録

初期の設計：Lambda + ECRでSLMを動かす

最初の設計では、SLM（llama-cli）をECRに格納したコンテナイメージに入れ、Lambda Container Image機能を使って10GBのメモリ制約内で動作させる構成にした。SlackのWeb-hook関連のシークレットはAWS Secrets Managerに格納し、Lambdaから読み込むことでセキュアな構成にしている。

しかし、llama-cliの呼び出し時にCore Dumpが発生した。

ERROR stderr: /bin/bash: line 1: 25 Illegal instruction (core dumped)
/packs/src/llama.cpp/build/bin/llama-cli -m /packs/models-gemma-2b-it-q4_0.gguf

今思えば、llama-cliのバイナリとLambdaの命令セット（CPU命令セット）の相違が原因ではないか？と思われるが、当時は原因の特定に至らなかった。（2週間くらい頭を悩ませた記憶）

原因の特定に時間がかかりそうであったため、Bedrockを利用する方針に転換した。ただし、Bedrock単独では面白みに欠けると思われたため、DynamoDBを使ったRAG構成へと発展させることにした。

2回目の設計：DynamoDBでRAGを構築する←？

Bedrockを採用し、エンベディングにはTitan Embeddingsモデルを使うことにした。Bedrockだけでは面白みに欠けるため、DynamoDBとOpenSearch Serviceのzero-ETL統合を読んで、DynamoDBを基盤としたRAGを構築することにした。

この zero-ETL 統合により、Amazon DynamoDB を利用するお客様は、全文検索、あいまい検索、オートコンプリート、機械学習 (ML) 用のベクトル検索など、Amazon OpenSearch Service の強力な検索機能を使用して、ユーザーエンゲージメントを高め、アプリケーションに対する満足度を向上させる新しいエクスペリエンスを提供できるようになりました。

この zero-ETL 統合では、Amazon OpenSearch Ingestion を使用して、Amazon DynamoDB と Amazon OpenSearch Serviceの間でデータを同期します。データを同期する必要がある DynamoDB テーブルを選択すると、Amazon OpenSearch Ingestion は、データが使用可能になってから数秒以内に Amazon OpenSearch マネージドクラスターまたはサーバーレスコレクションにデータを同期します。

また、インデックスマッピングテンプレートを指定して、Amazon DynamoDB フィールドが Amazon OpenSearch Service インデックスの正しいフィールドにマップされるようにすることもできます。また、複数の DynamoDB テーブルのデータを 1 つの Amazon OpenSearch Service マネージドクラスターまたはサーバーレスコレクションに同期して、複数のアプリケーションにわたる総合的なインサイトを得ることができます。

― Shuhei Fukami, Amazon DynamoDB の Amazon OpenSearch Service とのゼロ ETL 統合が利用可能になりました

しかし、ここで（自身の読解力の）基本的な問題に気がついた。DynamoDBはKey-ValueのNoSQLデータベースであり、単独ではベクトル検索に対応していない。RAGに必須のセマンティック検索を実現するためには、ベクトルDBの機能が必要である。この記事に明確に書いてあるのは、OpenSearchとの統合をすることで、ベクトル検索などができるようになると記載されているが、その部分を見落としていたのである。（ここでまた1週間くらい時間を使った）

よって、zero-ETLを利用してOpenSearch Serviceとの統合が必要という結論に至り、設計を見直した。

3回目の設計：OpenSearch Serviceを中核に据える

3回目の設計では、OpenSearch Ingestionを使いDynamoDBとOpenSearch Serviceをzero-ETLで統合した。テキストエンベディングとセマンティック検索はBedrockに集約し、サービスごとの役割分担を明確にすることができた。

実際にSlackから動作確認を行うと、ベクトル検索が機能していることが確認できた。大したデータを登録していないため回答の精度はまだまだだが、DynamoDBに登録したデータを元に回答を生成しようとしていることは確認できた。

出力テキスト

{
 "query": "@AWS Bedrock こんにちは",
 "prompt": "ユーザーからの質問: @AWS Bedrock こんにちは\n\n関連する情報：\n1. この文章はDynamoDBに登録するサンプルデータです。DynamoDBはAmazon Web Servicesが提供する完全マネージド型のNoSQLデータベースであり、高速で柔軟なスキーマを特徴としています。この文章には200文字程度の内容が含まれています。サンプルとして登録される内容は、主に日本語のテキストデータを取り扱います。(スコア: 0.34)\n\nこれらの情報を基に、質問に回答してください。",
 "answer": [
 {
 "tokenCount": 72,
 "outputText": "\n200文字程度の内容が含まれています。サンプルとして登録される内容は、主に日本語のテキストデータを取り扱います。\nこの文章はDynamoDBに登録するサンプルデータです。DynamoDBはAmazon Web Servicesが提供する完全マネージド型のNoSQLデータベースであり、高速で柔軟なスキーマを特徴としています。",
 "completionReason": "FINISH"
 }
 ]
}

ただし、この構成にはDynamoDBを不必要に残してしまっている点がある。DynamoDBストリームの検証をしたかったので問題はないが、OpenSearch単独で使う方法も検証する必要がありそうである。

今回の検証で得たもの

RAGの本質は「回答精度の向上」ではない

今回の構築を通じて、RAGに対する理解が変わった。

RAGは、生成AIの回答精度を向上させるものではなく、生成AIが利用できる情報に制限を加えるものと理解した方が良い。これにより、回答が一般論に限定されたり、ハルシネーションによる影響範囲を制御できる。

生成AIは既に大量の情報を持っている。そして、我々だけが持つデータも、徐々に活用できるようになってきている。だからこそ重要なのは、「どこまでをAIに考えさせ、どこからが人間がルールに基づいて判断するのか」を設計する仕組みである。

機械的に判断するもの、つまりルールが厳密に定義できるものには、生成AIを使ってはならない。この線引きの設計こそが、RAGの構築においても中心的な課題になる。

OpenSearchを中核に据えることの本質的なメリット

Bedrock単独でもRAG機能は「Amazon Bedrock Knowledge Bases」として統合されている。では、なぜあえてOpenSearch Serviceを中核に据えたのか。

構築し、中の仕組みを理解してようやく分かりつつあるので結果論だが、AI技術者とアプリケーション開発者の責任境界を明確に分離できることにある。

OpenSearch ServiceはConnectorを介してBedrockと統合している。この構成では、以下のように役割を分けることができる。

AI技術者の役割：

OpenSearch ServiceとBedrockの統合
利用するモデルの選定
内部で動作するPipeline（検索、RAG、推論フロー）の設計

アプリケーション開発者の役割：

データの登録
推論・検索結果の取得
アプリケーションロジックの実装

Bedrock単独構成では、この責任境界を明確に引くことが難しい。これはBedrockが悪いという話ではなく、「アプリケーションとAIを一体で設計する思想」に近いためである。OpenSearchを挟むことで、AI側とアプリケーション側がそれぞれ独立して開発・改善できるレイヤ構造が実現できるのである。

ユースケースの例

今回の構成を応用したユースケースを2つ紹介する。

FAQチャットボット

社外に公開しているFAQの情報をクロールし、DynamoDBに格納する。DynamoDB Streams経由でOpenSearch Ingestionのエンベディング処理を通し、OpenSearch Serviceにデータを流す。API GatewayからLambda関数を呼び出し、Search Pipelineを介してOpenSearch/Bedrockで処理したデータをクライアントに返却する構成である。

ポイントは、DynamoDBの中で role のようなキー属性を定義しておくことで、Ingest Pipelineでフィルタをかけ、indexに保存するデータを制御できることである。この構成であれば、複数のデータソースを権限に応じて同様のインタフェースで使い回すことができる。

ログ解析とメディエーション

WebサーバのアクセスログをCloudWatch Logsに集約し、Kinesis Data StreamsでDynamoDBに転送する。CloudWatch Contributor InsightsでHTTPレスポンスコードがエラーのトップ10を分析し、特に対応が必要なものをLambda経由でOpenSearch/Bedrockにエラーメッセージと原因を解析させる。

ここでも設計のポイントは明確である。機械的に分析しなければいけないもの（エラーのトップ10の抽出）と、AIに分析させなければいけないもの（エラー原因の推論）を分け、AIが扱うデータの境界線をシステム上も運用上も明確にしている。AIが分析すべきデータを絞ることで、トークンの無駄遣いによるコスト増やハルシネーションの影響範囲を抑えることができる。

生成AI時代に求められる「構造設計能力」と試行錯誤の重要性

今回の構築を通じて、改めて感じたことがある。

生成AIは、人間の「構造設計能力」を強く要求する。人間が変数、あるいはデータや処理の範囲の設計を担い、その範囲での処理や思考はAIが行うという役割分担は機能する。しかし逆に言えば、人間がすべきこと、つまり人間が持つ考えに対しては、AIを介入させてはならないのである。

また、机上の設計と実装は容易に分離する。机上の設計で動くと思っていても、実際に動かしてみるとCore Dumpしたり、そもそもAWSサービスをきちんと理解していなかったりすることで足元を掬われる。特にAWSなど日進月歩のサービスを使ったシステムでは、信頼できる情報を調べた上でPoCを必ず実施することが重要である。

仮説を素早く検証し、実現可能な構成を見極めるスキルが、これからの時代には不可欠になる。

まとめ

Slack連携のRAGチャットボットをAWS上に構築する過程で、3回の設計見直しを行った。Lambda + ECRでのSLM実行、DynamoDBベースのRAG、そしてOpenSearch Serviceを中核としたRAGという変遷を経て、以下の知見を得た。

RAGは「回答精度の向上」ではなく「AIが利用できる情報の制御」と理解すべきである
OpenSearchを中核に据えることで、AI技術者とアプリケーション開発者の責任境界を明確に分離できる
机上の設計と実装は容易に乖離するため、PoCの実施が不可欠である
生成AI時代において、人間に求められるのは「どこまでをAIに任せ、どこからを人間が判断するのか」を設計する構造設計能力である。つまり、「何をAIに渡さないか」を決める能力でもある。

今後の課題として、ECRでllama.cppが動作しなかった原因（CPU命令セットの相違）の検証と、SageMakerとの比較（開発者の責任境界の設け方の違い）を進めていく予定である。

メモリ10GB、エフェメラルストレージ10GB、上限処理時間15分 ↩︎

GitHub Pagesに独自ドメインを設定する方法（ムームードメイン + Hugo）

Sat, 07 Feb 2026 00:00:00 +0900

GitHub Pagesでブログを公開していると、sonohen.github.ioのようなデフォルトのドメインではなく、独自ドメインでアクセスしたくなる。今回、ムームードメインで取得したドメインをGitHub Pagesに設定したので、その手順と遭遇したトラブルについてまとめる。

全体の流れ

独自ドメインの設定は、大きく以下の5つのステップで行う。

ムームードメインでのネームサーバ設定
GitHub側でのドメイン認証
CNAMEファイルの作成
GitHub側でのDNS設定チェック
HTTPS通信の強制

順番に説明していく。

ムームードメインでのネームサーバ設定

GitHub公式ドキュメントを参考に、ムームーDNSで以下のレコードを設定する。

サブドメイン	種別	内容
-	A	185.199.108.153
-	A	185.199.109.153
-	A	185.199.110.153
-	A	185.199.111.153
www	CNAME	sonohen.github.io

Aレコード4つはApexドメイン（sonohen.net）をGitHub PagesのIPアドレスに向けるためのもので、CNAMEレコードはwwwサブドメインをGitHub Pagesに向けるためのものである。

確認方法

% dig www.sonohen.net

; <<>> DiG 9.10.6 <<>> sonohen.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46977
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;sonohen.net. IN A

;; ANSWER SECTION:
sonohen.net. 3367 IN A 185.199.109.153
sonohen.net. 3367 IN A 185.199.111.153
sonohen.net. 3367 IN A 185.199.108.153
sonohen.net. 3367 IN A 185.199.110.153

;; Query time: 19 msec
;; SERVER: 2400:4051:4682:c200:32be:3bff:fe4d:9964#53(2400:4051:4682:c200:32be:3bff:fe4d:9964)
;; WHEN: Sat Feb 07 22:47:33 JST 2026
;; MSG SIZE  rcvd: 104

GitHub側でのドメイン認証

GitHub > Profile > Code, planning and automation > Pages > Add a domainから、ドメインの認証を行う。指定されたTXTレコードをムームーDNSに登録し、認証を通す。

この認証が行われないと、後続のDNSレコードチェックが失敗するため、必ず先に済ませておく。

CNAMEファイルの作成

GitHub Pagesが独自ドメインを認識するために、CNAMEファイルをリポジトリに配置する必要がある。

www.sonohen.net

Hugoでstackテーマを使っている場合は、themes/stack/static/CNAMEに配置する。こうすることで、ビルド時に公開ディレクトリのルートにCNAMEファイルが生成される。

GitHub側でのDNS設定チェック

リポジトリ > Settings > Code and automation > Pages > Custom domainに独自ドメインを入力すると、GitHubがDNS設定をチェックしてくれる。

このチェックが通るためには、事前に以下の3つが完了している必要がある。

ネームサーバにA、TXT、CNAMEレコードが追加されていること
CNAMEファイルが公開され、外部からアクセス可能であること
GitHubでドメイン認証が完了していること

HTTPS通信の強制

リポジトリ > Settings > Code and automation > Pages > Enforce HTTPSにチェックを入れることで、HTTP通信が無効になり、HTTPS通信が強制される。

ハマったポイント

設定自体はシンプルだが、2つのトラブルに遭遇した。

ドメイン認証が通らない

ムームーDNSでTXTレコードを作成する際、ホスト名に_github-pages-challenge-sonohen.sonohen.netと入力していた。しかし、ムームーDNSでは.sonohen.netが自動的に付与されるため、実際に作成されたホスト名は_github-pages-challenge-sonohen.sonohen.net.sonohen.netになっていた。

ホスト名を_github-pages-challenge-sonohenに修正することで解決した。

確認方法

% dig _github-pages-challenge-sonohen.sonohen.net +nostats +nocomments +nocmd TXT

; <<>> DiG 9.10.6 <<>> _github-pages-challenge-sonohen.sonohen.net +nostats +nocomments +nocmd TXT
;; global options: +cmd
;_github-pages-challenge-sonohen.sonohen.net. IN TXT
_github-pages-challenge-sonohen.sonohen.net. 3541 IN TXT "ひみつ（でもないが）"

DNSチェックが通らない

Custom domainの認証が通らなかった原因は、GitHubがhttp://www.sonohen.net/CNAMEにアクセスできなかったためだった。

CNAMEファイルにはwww.sonohen.netを記載しておく必要があり、かつ外部からアクセス可能でなければならない。また、DNSチェックが通っていない時点ではHTTPS通信ができないため、HTTPでアクセスされる点にも注意が必要である。

対処として、以下の手順を踏んだ。

CNAMEファイルを作成し、static/CNAMEに配置
サイトをリビルド
http://www.sonohen.net/CNAMEにアクセスできることを確認

まとめ

GitHub Pagesへの独自ドメイン設定は、DNS設定・ドメイン認証・CNAMEファイル配置・DNSチェック・HTTPS強制の5ステップで完了する。特にムームーDNSでは、ホスト名にドメインが自動付与される仕様に注意が必要だった。

Zettelkastenで管理する情報は何で、どう管理すべきなのか

Sat, 31 Jan 2026 00:00:00 +0900

Zettelkastenに、何でもかんでも入れるべきではないという記事を書いた。

Zettelkastenを機能させ、また形骸化させないために、何でもかんでも入れるべきではない。

では、どのような情報を入れるべきなのか。この記事では、3つの論点に沿って考えたいと思う。

全ての情報を管理してはいけない

まず「何でも出来る」と聞いて、皆さんが思い浮かべるものの特徴はなんであろうか。私は「帯に短し、襷に長し」という特徴を思い浮かべる。

例えば、何でも出来るノートパソコンというのは、実に扱いに困る。グラフィックス性能が高く、ゲームができるとしよう。それでも、デスクトップ型のパソコンにグラフィックス性能は及ばず、また、バッテリーの持ちも悪くなる。何にしても中途半端になるのである。

同じことがZettelkastenにも言える。「何でも入っている」というのは、情報を検索する際には便利であるが、こと知の再生産を考えると、扱いに困る。有象無象、玉石混合な情報からは、何かを生み出すことは難しいからである。

例えば、十分に調査された内容と、街中を歩いていてふと閃いたアイデアが一つの場所にあるとして、それらを組み合わせて何かを生み出すことは難しい。アイデアを裏付ける情報があるのであれば、その情報と組み合わせて一定の見解を整理しておくことが重要であろう。

このようにZettelkastenには、吟味や精査が「ある程度」完了した情報を入れておくことで、情報のレベルを整えておくことが重要なのである。

自分の考え以外の情報を入れてはならない

Zettelkastenを「思考の再利用装置」と機能させるためには、中のノートが「自分の考えだけで構成されている」と信頼できる状態を維持し続けることが重要である。

Zettelkastenの関連するノートとして、Fleeting Notes（ひらめきやアイデアのノート）、Literature Notes（文献ノート）がある。これらは、ZettelkastenのPermanent/ Structured/ Index Notesを生み出すための補助的な位置付けにある¹。従って、走り書きや他者の意見をZettelkastenに入れるべきではない。

ここまでに述べてきた2点は、「再利用時のノイズを減らし、思考を引き出しやすい状態を維持すること」が目的となる。

ノートは、見返されることを前提に作るべきである

Zettelkastenの基本的な考え方は「ネットワーク型ノート」である。Webの世界と同じく、ノート間がキーワードによって繋げられ、ネットワークが作られる。関連を作り、辿り、新たな知を生み出していくという流れになる。

このような仕組みにおいて、ノートは少なくとも3回は見直されると考えている。

1回目は、ノートを作成するときである。まずは、ノートの内容を記述し、Structured Notesからリンクさせる。その上で、記述されている内容がAtomic Note（原子ノート）として成立しているか、再利用可能かという観点でチェックをし、必要に応じて見直す。

2回目は、ノートが他のノートから新たにリンクされたときである。新たな関連が生まれ、また、別と思われていたノートから関連が辿られるといったときに、ノートの記載内容を見直すことがある。例えば、再利用性を高めるためにはある程度の抽象化が必要になるが、切り口を変えてみたときに抽象化が不十分であったりする場合には、ノートの再利用性を高めるために記述内容を見直す。

3回目は、他のノートからリンクを辿って参照されたときである。何かしらの新しい、あるいは意外なつながりが生まれたときに見直される可能性が高い。また、共通項を抜き出した上で新たにノートを作り、関連を作っていくという場合である。

こう考えると、ノートというのは見返されることを前提に作るべきなのである。つまりどういうことか。たとえいつのノートであっても、ノートに背景情報など理解に必要な情報を含め、理解可能な状態を維持し続けなければならないということである。

では、全てをネットワーク型ノートで管理したい場合にはどうすれば良いか

管理単位を厳密に分けることを推奨したい。例えば、私の場合はZettelkastenとLiterature NotesをObsidianで運用しているが、それぞれVaultを分割している。

ObsidianはVault間のリンクをサポートしているため、Zettelkasten側からLiterature Noteにリンクを貼り、「自分の考えと文献」を分離しながら運用をしている。これにより、Zettelkastenの独立性は守られ、ノイズトなる情報は入り込まなくなる。また、Obsidianが持つネットワーク型ノートの利点を享受することもできるのだ。

Zettelkasten（ツェッテルカステン）で使うノートの種類と構成まとめ ↩︎

Zettelkastenを機能させ、また形骸化させないために、何でもかんでも入れるべきではない。

Wed, 21 Jan 2026 00:00:00 +0900

日々接する情報のうち「これは」という情報は、Zettelkastenに入れている。自分が知っていること、記録していること（= 既知の情報）を組み合わせたり、文脈の転換を行なったりすることで、新たな視点や価値を生みだす活動（これを知的生産活動といっている）に興味を持っている。その過程を支える実践的な方法としてZettelkastenが有効であると考え、今、試行錯誤しているところである。

Zettelkastenの仕組みは、ネットワーク型ノートで実装すべきである

Zettelkastenに似た仕組みとして、京大式カード（『知的生産の技術』（梅棹））がある。

詳しい説明は別の記事に譲るとして、これらに共通するのは、「原子的（Atomic）に書かれたノートや文脈の組み合わせを変えることで、新たな視点や価値を創造できることを目指している。」点にあると考えている。この文脈においては、ObsidianやScrapboxといった、いわゆる「ネットワーク型ノート」を使うことが望ましいと考えている。トップダウン型ノートでは実現が難しい。

ネットワーク型ノートを使うメリットは、知識の再構成によって新たな価値を創造できる点にある

では、ネットワーク型ノートを使うメリットはなんだろうか。

それは、すべてのノートがリンクで繋がっており、また、それぞれのノートが原子的（Atomic）な単位で書かれているが故に再利用可能であることだと考えている。ノートには、複数のポイントは書かれず、そのノート自体がZettelkastenにおける部品である。

例えば、レゴを思い出して欲しい。レゴは、部品であるブロックを組み合わせ、船や城などを作り上げることができる。これと同じことがネットワーク型ノートにも言えるのである。ノートの組み合わせによって、船でも城でも作り上げることができる。すなわち、知識を蓄積するだけでなく、再構成することによって新たな価値を創造できる点に、ネットワーク型ノートの本質的なメリットがあると言える。

再構成に必要な条件は2つある

そこで問題になるのが、再構成をするために必要な条件とは何かである。私は、以下の2つの条件があると考えている。

Zettelkastenの中ですべての情報を管理してはいけない
他者の情報（本の書き抜きや生成AIの生成物等）を含めてはいけない

まず「Zettelkastenの中ですべての情報を管理してはいけない」である。これは部屋の整理と同じである。有象無象の情報が混在してしまうと、再構成するにあたりどの情報があるのか、どれを使って良いのかが分からなくなってしまう。Zettelkastenの中には考えや経験など、あくまで自分の情報を入れておくことが重要なのである。

次に「他者の情報（本の書き抜きや生成AIの生成物等）を含めてはいけない」である。私は当初、「生成AIが探してきた文献や文章」をZettelkastenの中に入れてしまっていた。これは「自分の意見や主張を裏付ける情報がZettelkastenの中に存在する」という点で非常に便利なように思えたが、そのうち、問題が徐々に明らかになっていった。例えば、1つのノートに複数のテーマが書かれていたり、非体系的なタグが付与されてしまっていたのである。つまり、Zettelkastenの中身はノイズだらけで、検索可能性も落ちてしまったのである。

その後、私が取った手段は悪手であった。何をしたかというと、（その時に使っていたClaude Codeの）精度を高めようとしたのである。

例えば、スキルを使ってガチガチに固めたルールでノートを作成させたり、サブエージェントを使ってノートの中身をレビューさせるなど、本来論的にはすべきではないところに時間と労力を割いた。その結果、何が起こったかというと、Claude Codeの利用量制限には引っかかり、出来上がったノートは多少マシになったものの、結果的に「他者の意見が入っている」という点は何ら改善できなかった。

今は考えを改め、Zettelkastenには自分の考えしか入れておらず、心の平穏は保たれている。

情報の出所と活用方法は、厳密に管理すべきである

こうして考えてみると、何か特定のテーマの論点を整理したり、文献の検索までをAIにやってもらうのは結構なことだとは思う。また、Zettelkastenの中身を検索して、思いもつかないようなインサイトを提示してもらうのも良いだろう。

しかし、AIにノートを作成・校正させたり、メタデータ（タグなど）や構造を操作させてはならないと強く実感した。これをしてしまうと、それらのノートがノイズになってしまい、知的生産活動ができなくなってしまう。

SNSを見ていると、個人の知的ノートと生成AI（Claude CodeやAntigravityがホットな話題のようだ）を組み合わせてコンテンツを量産するという記事、あるいは情報商材が出回っており、カオスな状態になっていると感じる。

私も、こうした仕組みを試した結果をnoteに書いたのだが、実際にはその仕組みは機能しないと思っている。なぜなら、これを本当の意味で実現しようと思うと、相応の設計能力、それに沿った運用が求められるからである。それができる人が、果たしてどれだけいるだろうか。できなければ、何もない状態からAIにコンテンツを作らせるのと何ら変わらない結果となってしまうのは火を見るよりも明らかである。

すなわち、例え生成AIが自由に使えるようになったとはいえ、それを使った知的生産活動には、AIの使い方だけではない「知識」の高度な運用能力が引き続き求められている点に留意する必要がある。

参考記事

この3ヶ月で得た、仕事におけるAI活用と、人間の役割に関する重要な気づき

読み放題よりも、Kindle Unlimitedの本当の価値は別にあった

Wed, 21 Jan 2026 00:00:00 +0900

正直に言うと、Kindle Unlimitedにはあまり期待していなかった。

「月額980円で読み放題」と言われても、読みたい本なんてそんなにないだろうと思っていた。

ところが、しばらく使ってみて気づいた。

Kindle Unlimitedの本当の価値は、「読み放題」ではない。それは、自分の中にあった学びの心理的ハードルを壊してくれたことだった。

同じテーマを複数の視点で学ぶことの重要性

あるテーマについて深く理解しようとする時、1冊の本だけでは不十分だと感じたことはないだろうか？

例えば、行動経済学について学びたいとする。その時、以下のような異なる視点の本を読むと理解が深まる。

NewsPicksのような実務寄りの本
アマチュアが書いた入門書
プロが書いた専門書

こうした異なる水準や視点の3〜4冊を一気に読むことで、個別の事実ではなく、なんとなくの知識体系が頭の中に形成される。単一の本よりも、複数の視点を組み合わせることで、より堅牢で応用可能な理解が得られるのだ。

でも、複数冊買うのは心理的ハードルが高い

ここで問題がある。同じテーマの本を複数冊購入するのは、意外と心理的・経済的な障壁が高い。

「もう1冊買っても本当に読むかな？」
「さっき買った本で十分かもしれない」
「3冊も買ったら数千円になる…」

こうした躊躇が、学びの深さを制限してしまう。

Kindle Unlimitedが下げる「学びの障壁」

ここでKindle Unlimitedの真価が発揮される。定額制なので、同じテーマの本を何冊読んでも追加コストがゼロだ。

この「追加コストゼロ」という安心感が、複数の視点から学ぶという行動を後押ししてくれる。経済的な障壁がなくなることで、心理的な障壁も下がるのだ。

「気になるテーマがあれば、関連する本を3〜4冊まとめて読んでみよう」という発想が自然と生まれる。これこそが、Kindle Unlimitedの本当の価値だ。

さらに効率を上げる：要約サービスとの組み合わせ

学びの効率をさらに高める方法がある。それは要約サービスを読書前の準備段階として活用することだ。

具体的には以下の流れとなる。

気になるテーマについて、Flierなどの要約サービスで概要を把握する
基礎的な枠組みができた状態で、Kindle Unlimitedで本を読む

この段階的なアプローチにより、本を読む際に既に基礎的な枠組みが形成されているため、知識の定着に大きく活かせる。要約で全体像を把握してから詳細を読むことで、情報がより効果的に統合されるのだ。

まとめ：Kindle Unlimitedは「学びの実験場」

Kindle Unlimitedの価値を「何冊読めるか」で測るのはもったいない。本当の価値は、同じ情報に角度を変えて何度も触れることの心理的障壁を下げていることにある。

要約サービスと組み合わせれば、さらに効率的な学習サイクルが回せる。

あなたはKindle Unlimitedをどう活用している？「読み放題」ではなく「学びの実験場」として使ってみると、新しい発見があるかもしれない。

画面を分けるだけで「学び」が変わる。Pixel 10 Pro Foldで実現する新しい読書術

Sun, 11 Jan 2026 00:00:00 +0900

これまでは、ノートパソコンを広げて読書をするのが私のスタイルでした。左側に電子書籍のKindle、右側にメモ用のアプリを開き、気づいたことを音声で入力していく。この「読み」ながら記録する流れが、知識を身につける一番の近道だったからです。

しかし、自宅、あるいは外出先でパソコンを取り出すのは、どうしても手間がかかります。もっと手軽に、それでいて本格的に学びたい。そんな悩みを解決してくれたのが、画面を大きく広げられるスマートフォン「Google Pixel 10 Pro Fold」でした。

このデバイスの最大の特徴は、一つの画面を二つに分割して、別々のアプリを同時に動かせることです。電子書籍で本を読みながら、もう片方でGoogle Keepを開く。パソコンで行っていた効率的な学習環境が、手のひらの上で完全に再現されました。

驚くほどスムーズな「声のメモ」が、思考を止めない

特に驚いたのが、Gboardの音声入力の精度です。読み進める中で心に残ったフレーズを口に出すと、魔法のようにスラスラと文字に変わります。反応が非常に速いため、せっかく思い浮かんだアイデアを忘れる前に、確実に記録に残せるようになりました。

以前は「スマホでメモをするのは面倒」という先入観がありましたが、今ではパソコンよりも快適に感じています。場所を選ばず、思い立った瞬間にアウトプットを開始できる。このスピード感こそが、忙しい日々の中で学びを継続する鍵になると実感しています。

さらにこの仕組みは、本だけでなく動画での学習にも応用できます。画面の左側にYouTubeやオンライン講座を流しながら、大事なポイントを右側のGoogle Keepに音声入力で書き留める。ツールが連携して動く様子は、まるで自分専用の学習室を持ち歩いているような感覚です。

Androidユーザーなら、今すぐその恩恵を受けられる

とはいえ、Google Pixel 10 Pro Foldは決して安い買い物ではありません。その価格に、導入をためらってしまう方も多いでしょう。ですが、今回お伝えした「効率的な学習体験」の本質は、実は多くのAndroid端末で今すぐ体験できるものです。

画面分割機能や、高精度な音声入力は、Androidが共通して持っている強みです。まずは手持ちのスマートフォンで、読書アプリとメモアプリを並べてみてください。そしてキーボードで打つ代わりに、マイクに向かって自分の考えを話してみてください。

たとえ画面が少し小さくても、声でアウトプットする爽快感とスピードは十分に実感できるはずです。道具の良さを引き出す工夫一つで、いつものスマートフォンが強力な学習ツールへと進化します。これは試してみない手はありません。

スマートフォン一台で、未来の自分への投資を加速させる

これからの時代、スマートフォンは単に情報を眺めるだけの道具ではなく、自分を成長させるための「相棒」になっていくでしょう。高性能な機能が手元に凝縮されたことで、隙間時間はすべて、価値あるアウトプットの時間へと姿を変えます。

「スマホだけで本当に勉強ができるのか」と疑問に思う方もいるかもしれません。しかし、道具を賢く組み合わせることで、私たちは場所や時間の制約から解放されます。まずは一歩、手元のデバイスで「読みながら話す」習慣を始めてみませんか。

日々の小さなアウトプットの積み重ねが、いつか大きな成果となって自分を助けてくれるはずです。新しい道具を味方につけて、自分なりの学びのスタイルをアップデートしていく。そんな前向きな挑戦を、これからも楽しんでいきたいと思います。

Emacs + DDSKK on kittyな環境で日本語変換がバグる

Tue, 02 Dec 2025 00:00:00 +0000

環境

Arch Linux
tmux 3.6
GNU Emacs 30.2 + DDSKK
kitty 0.44.0

事象

以下のように入力すると、不正な文字列が入力される。

KiGasuru -> 気gがする

解消方法

以下のようにすることで、完全な解消は難しいものの軽減はできた。

~/.config/kitty/kitty.conf

kitty_keyboard_protocol no

~/.local/bin/emacs-noime

#!/bin/sh -e

unset GTK_IM_MODULE
unset QT_IM_MODULE
unset XMODIFIERS
unset DefaultImModule
unset GLFW_IM_MODULE

export NO_AT_BRIDGE=1

exec emacs -nw "$@"

今後は、 ~/.local/bin/emacs-noime を kitty から呼びだすことで、不正な文字が極力残らないようにして作業を実施できるものと思われる(完全解消するためには、 emacs -nw を止めるしかない)。

その後の検証の結果

結局、上記は効果がなかったとは言えないが、もっとも効果がありそうなのは以下の対策であった。

~/.config/kitty/kitty.conf

programs.kitty.keybindings = {
 "ctrl+j" = "discard_event";
}

その後の検証の結果(2)

結局、劇的な効果が見込まれず emacs -nw をtmuxの中で動かすことは止めにした。

qutebrowserがウェブサイトを描画しない

Sun, 23 Nov 2025 00:00:00 +0000

かつてよりLinux環境ではFirefoxを愛用していたのですが、最近ではもっぱらqutebrowserを愛用しています。vimの操作方法を使えるのが便利で、マウスを使わずともほとんどの操作をキーボード主体でできることから、i3-wmとも非常に相性が良いです。

しかし、そのqutebrowserをArchLinuxにインストールしたところ、どうにもまともに動かない状況で、2-3日ハマりました。結論は、Xorgのドライバーをきちんとインストールしていなかったことでした。解決に至るまでの状況と教訓をまとめておきます。

起こっていたこと

スタートアップに指定しているDuckDuckGoのページが表示されない。ロードが終わっていることはステータスバーから分かるものの、画面は真っ白の状態。まれに画面がちらつき、アヒルのロゴが表示される状況。
操作がまともに出来ない。コマンドを受け付けない。

調査(1) qutebrowser/qtwebkitのバージョンによる不具合の有無

まず最初に疑ったのが、ArchLinuxにインストールされている qutebrowser と、それが利用している QtWebEngine のバージョンによる不具合の有無です。私の環境では、2025年11月21日現在で以下のバージョンがインストールされていました。

qutebrowser v3.6.1
PyQt 6.10.0
PyQt6.QtWebEngineCore 6.10.0

これらのバージョンは、正常に動作しているSlackware -current on ThinkPadと同じであったので、インストールされているバージョンに不具合があるというわけではなさそうだ、という結論に到達しました。(一応、ChatGPTにも調査させ、不具合がでていないことは調べました。)

調査(2) ドライバの問題

次に疑ったのがグラフィックドライバの問題です。疑った根拠は以下の2つです。

Xorgの設定をまともにしていなかったと思い出したこと
qutebrowser --version の出力結果を眺めていたところ、qutebrowserの内部ではChromiumをベースとしたQtWebEngineが動作していることに気が付いたこと

利用している端末はHP EliteBook 630 (G9)で、これには12世代のIntel CPU(12th Gen Intel(R) Core(TM) i5-1235U)が搭載されています。使用しているグラフィックボードはオンボード(統合チップセット)で、Intel Iris Xe Graphicsです。Xorg - ArchWikiによると、この世代のチップには xf86-video-intel を使うのではなく、代わりに mesa を使うように記載があります。

なるほどと思い /var/log/pacman.log を調べると、 extra/mesa がインストールされていないことが判明しました。 extra/x86-video-intel を削除したのち、 extra/mesa をインストールして端末を再起動したころ、qutebrowserが正常に動作するようになりました。

教訓

当たり前のことですが、ソフトウェアの動作環境はきちんと確認するようにすべきでした。今回の場合、 qutebrowser --verion を実行すれば、どのバージョンのソフトウェアが動作しており、かつqutebrowserに認識されているのかを確認することができます。その中で、OpenGLがどのドライバーによって動作するのかも知ることができるので、最初から丹念に確認しておけば今回の調査期間を短縮できたはずです。今回気が付いたのは3日目でした。

また、Slackwareでqutebrowserを特に何も気にすることなく使えていたのは、あらかじめ必要なドライバーがインストールされており、それが自動検出によって使われていたお陰であろうと思います。ArchLinuxはカスタマイズ性が高いのですが、それはすなわち全てを自分で管理しなければいけないということにあるので、まずはきちんと設定をする、というところを怠るべきではありませんでした。(最近のLinuxの自動検出/自動設定に甘えていました)

今回のこの件を機に、自分のスキルはまだまだだなと思いつつ、利用者の目線からするとある意味ではシンプルに動作している点がさすがLinuxだと思ったので、今後も精進していこうと思います。

SlackwareでThinkPadの液晶の明るさを変える

Sun, 02 Nov 2025 00:00:00 +0000

X.comでもいくつかポストしていますが、先日からSlackwareでi3を使用しています。環境構築作業のなかで最も優先度が低かったのが液晶の明るさを変更するための仕組みであったのですが、今日、ようやく実装しました。

何かツールを入れるのもなぁと思っていたところ、 /sys/class/backlight/amdgpu_bl0/brightness を書き換えればよいということがわかり、以下のようなスクリプトを作っておきました。

#!/bin/sh -e

#
# Usage:
# brightness.sh 1000 (for Brighter)
# brightness.sh -1000 (for Darker)
#

FILE=/sys/class/backlight/amdgpu_bl0/brightness
CURRENT_BRIGHTNESS=`cat $FILE`

TARGET_BRIGHTNESS=$(( $CURRENT_BRIGHTNESS + $1 ))
echo $TARGET_BRIGHTNESS > $FILE

これを、以下のように設定することでキーボードから呼び出すようにしました。

bindsym XF86MonBrightnessUp exec --no-startup-id sudo ~/.local/bin/brightness.sh 4000
bindsym XF86MonBrightnessDown exec --no-startup-id sudo ~/.local/bin/brightness.sh -4000

私だけしか使っていないシステムなので、 sudo は NOPASSWD で実行できるようにしています。

これで、設定を再読み込みすれば、キーボードから液晶の明るさを調整することができるようになります。

Slackware -currentでHEIC対応のdigiKamを動かす

Mon, 20 Oct 2025 00:00:00 +0000

TL;DR

Slackware -currentのImageMagick (7.1.2-7)は --with-heic=yes でコンパイルされていないため、それを使っているdigiKamでもHEIC/HEIFフォーマットの画像を扱うことができない。同じ理由で、Gwenviewでも扱うことができない。

そもそもの発端

つい最近までDebian GNU/Linuxを使っていたのですが、思うところがありここ数日でSlackware -currentに環境を移行しました。kernel/gcc/emacsを自前でコンパイルし、色々な試行錯誤を繰り返しながら、なんとか必要な作業ができるようになってきたことから、本格的にデータを移行することにしました。

これといった理由は特に無いのですが、趣味の写真をさっさと再開できるようにということで、まずは写真のデータをSlackwareに移行することにしました。

HEICフォーマットの画像がdigiKamに表示されない

HEICフォーマットはiPhone等で使われる形式で、同程度の視覚品質を得るためにはJPEGの50-60%程度のファイルサイズで済むといわれています。つまり、容量に制約のあるスマートフォンや、クラウドサービスの容量を節約したい場合にHEICを使うことが良いのではないかと思われます。私も、iPhoneでHEICが使われるようになってからというもの、iPhoneで撮る写真はすべてHEIC形式になりました。

それらの写真をdigiKamに取り込もうとした時に、サムネイルもプレビューも表示されないので「どうなってんだ？」と思い調査したところ、まず判ったのは libheif がシステムにインストールされていないことでした。

`libheif` をインストールする

libheif は libaom と libde265 に依存している。まずはそれらをシステムにインストールする必要があるので、準備する。 libaom はdarkskygit / libaomから入手することができる。また libde265 はstructurag / libde265から入手できるので、それぞれREADMEを参考にコンパイルしてパッケージを作り installpkg でインストールしておく。

次に libheif をインストールする。 libheif はstructurag / libheifから入手できるので、こちらもREADMEを参考にコンパイルしてパッケージを作り installpkg でインストールしておく。途中 /usr/lib64/libaom.a が見付からないというエラーが出るので ln -s /usr/lib64/libaom.a /usr/local/lib64/libaom.a としてsymlinkを張っておく。

ここまで実施してdigiKamを起動しても状況は変わらなかった。なぜだと考え、調べているうちに、どうやらdigiKamはバックエンドにImageMagickを使っていそうだということがわかり、では、ImageMagickでHEIC/HEIFは有効になっているのだろうかと調べたところ有効になっていなかったのであった。

$ magick -list format | grep HEIC # 結果は何も表示されなかった => 無効
$ magick -list format | grep HEIF # 結果は何も表示されなかった => 無効

ImageMagickを `--with-heic=yes` つきでインストールする

ImageMagicは、currentのソースコードをもとにコンパイルする。 imagemagic.SlackBuild の中に記載されている ./configure に対し --with-heic=yes を指定したうえでパッケージを作成し、インストールする。

ここまで実施した上でdigiKamを開くと、HEICフォーマットの画像が表示されるようになっているはずである。

DolphinとGwenviewでもHEICを扱いたい場合は、KImageFormatsをHEICサポートつきでコンパイルし、インストールする必要がある

ここまで実施しても、まだDolphinやGwenviewでHEICを表示することはできない。それらでHEICを扱うためには、KImageFormatsをHEICサポートつきでコンパイルし、インストールする必要がある。 cmake の引数に -DKIMAGEFORMATS_HEIF=on を指定してコンパイルし、パッケージを作成、インストールする。

こうして無事、私の写真ライブラリはSlackwareマシンに移行されたのでした。

まとめ

こうしてまとめてしまうと何てことのない作業なのですが、実際にはログを見たり、インターネットで調査したり、横道に逸れたりしながら調査して、結構時間を喰ったように思います。が、まずはHEICがきちんと取り扱える環境になってめでたし、めでたし。

こういう調査は知識を身に付けるよい機会であるので、きちんと記録を取りながら対応し、知識を整理していきたい。今回は、作業ログをChangeLogのフォーマットで記録しておいたので、それを参考にしながらこの記事を書きました。

Debian GNU/Linux 13 (trixie)の4K出力が安定しない件を解決する

Mon, 13 Oct 2025 00:00:00 +0000

私は普段、Debian GNU/Linux 13 (trixie)をThinkPad E14 (Gen 3)で運用しており、外付けモニターとしてJapanNextの4Kモニターを使用しています。4K出力に対応しておりながら安価である点が気に入っています。

さて、その環境も、HDMI出力が安定せず、画面が表示されたりされなかったりで作業にならない状況が続いていました。どうもXがEDIDをモニターから取得するまでのタイムラグが原因のように思えましたので、環境決め打ちになってしまうのが気にはなりますが、以下のように対処をしました。

ここに記述している内容はX向けの設定ですが、結果的にXWayland経由で設定が反映されていることになります。

問題の切り分け

まずは物理的な問題を除外しました。

モニター自体は正常か？: 手元にあるMacBookを使ったところ正常に4K出力できたので、問題は無いと判断した。
HDMIケーブル自体は正常か？: 手元にあるMacBookに接続してみたところ正常に4K出力できたので、問題は無いと判断した。
ThinkPadのHDMIポートに問題は無いか？: 手元にある他のモニター(FullHD)に接続してみたところ正常に出力できたので、問題は無いと判断した。

この結果、物理的なハードウェアの問題ではなく、モニターとThinkPadの間の通信(ネゴシエーション)がうまくいかない場合がある、という仮説にいたりました。

ネゴシエーションの肝となる `EDID (Extended Display Identification Data: 拡張ディスプレイ識別データ)`

EDIDは、モニターが自分自身の仕様をコンピュータに伝えるデータです。具体的には以下の情報を含みます。

対応解像度(例：1920x1080、3840x2160)
リフレッシュレート(例：60hz)
色深度やカラーフォーマット
製造情報
タイミング情報(垂直/水平同期)

通常、コンピュータはEDIDを参照して自動的に最適な解像度やリフレッシュレートを設定します。EDIDのやり取りが失敗すると、画面が表示されなかったり、 xrandr が BadMatch エラーを返したりします(追記：これは、Waylandで実行すると出るエラーです)。

モニターから取得したEDID情報をXWayland経由で読み込む

つまり、モニターとやり取りをして解像度等を決定するのではなく、あらかじめEDIDを取得しておき、それをXから読み取るようにしておけば、ネゴシエーションに失敗する可能性は低いわけです。ただ問題は、EDIDを取得するためにはきちんと画面出力されている必要があるということで、そこまではなんとかする必要があるということです。全く表示されない場合には、この手段は使えないと思います。

EDIDを取得する

/sys/class/drm/card0-HDMI-A-1/edid からダンプしておきます。ここは環境に依存しますので、どのパスからダンプすればよいのかは xrandr の情報を参考にして決めてください。

$ sudo mkdir -p /etc/X11/edid/
$ sudo cat /sys/class/drm/card0-HDMI-A-1/edid > /etc/X11/edid/JAPANNEXT_JN-280IPS4KR.bin

Xの設定

/etc/X11/xorg.conf.d/10-monitor.conf を編集します。

Section "Monitor"
 Identifier "HDMI-1"
 Option "CustomEDID" "HDMI-1:/etc/X11/edid/JAPANNEXT_JN-280IPS4KR.bin"
EndSection

ゴミデータの削除

~/.config/monitors.xml が悪さをする可能性があるので、消しておきます。

Waylandを再起動

sudo systemctl restart display-manager によりWaylandを再起動し、正常に画面出力されることを確認します。また、HDMIケーブルを何回か抜き差ししても、毎回、安定して画面出力されるかを確認します。

制約

この方法を使うと、HDMI接続時に毎回、JapanNextのEDIDを参照することになるので、他のモニターによっては出力できなくなる可能性があります。環境がある程度固定的であればこの方法は有効ですが、そうでない場合(持ち歩き用途など)では使えない可能性もあります。
画面が全く表示されない場合にはEDIDが取得できないため、この方法は使えません。
サスペンドからの復旧時には、HDMIケーブルを抜線後にログインし、HDMIケーブルを差し込んだあと display-manager を再起動する必要があります。 sudo systemctl restart display-manager

Debian GNU/Linux 13 (trixie)でSwiftを動かす

Sun, 12 Oct 2025 00:00:00 +0000

Swift は、Apple社が開発をしているプログラミング言語で、主にApple製品で動作させるソフトウェアを開発するために使用されるものですが、オープンソース化されてからというもの、Linuxなどサーバサイドで動作するソフトウェアの開発にも使われているようです。

今回は、たまたま目新しいということで、インストールしてみました。

Swiftをインストールする

Install Swiftを参考にすればインストール自体は簡単にできます。

$ cd
$ mkdir swiftly
$ cd swiftly
$ curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz
$ tar xvzf swiftly-$(uname -m).tar.gz
$ sudo ./swiftly init --quiet-shell-followup
$ sudo apt install libstdc++-12-dev # Swiftlyからインストールを求められた場合のみ
$ . "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh"
$ hash -r

~/.bashrc にも、以下を追記しておきます。

# Swift
. "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh"
hash -r

`Hello World` してみる

swift にパスが通っていることを前提に、以下のコマンドを実行します。

$ mkdir helloworld
$ cd helloworld
$ swift package init --name HelloWorld --type executable
$ swift run HelloWorld

すると、以下のように実行されます。初回はとにかく遅く、Hello Worldだけにも関わらず約5秒の処理時間が掛っていました。

Building for debugging...
[8/8] Linking HelloWorld
Build of product 'HelloWorld' complete! (4.99s)
Hello, world!

2回目は以下のようにキャッシュが効いているのか、速くはなってはいますが、それにしても遅いですね。

[1/1] Planning build
Building for debugging...
[1/1] Write swift-version-3F9C5CDD8FC5382D.txt
Build of product 'HelloWorld' complete! (0.20s)
Hello, world!

EmacsでSwiftを使ってみる

当然、EmacsでもSwiftを使うことができます。私の場合、現時点でSwiftで本格的にプログラムを書く予定はなく、 org-babel で少し勉強したいと思っている程度なので、 ob-swift と swift-mode を導入することにしました。

PATHを通す

以下のような設定を ~/.emacs に入れることにより、Emacsを起動した際にShellの設定ファイルを読んでパスを通してくれます。事前に、 M-x package-install で exec-path-from-shell をインストールしておく必要があります。

(when (memq window-system '(mac ns x))
 (exec-path-from-shell-initialize))

`ob-swift` と `swift-mode` をインストールする

M-x package-install から ob-swift と swift-mode をインストールしておきます。前者は org-babel でSwiftを実行するために必要、後者はシンタックスハイライトをするために必要となります。

`org-babel` でSwiftを有効化する

以下のような設定を ~/.emacs に入れることにより org-babel でSwiftが実行できるようになる。

(org-babel-do-load-languages
 'org-babel-load-languages
 '((swift . t)
 (emacs-lisp . t)))

この例では、SwiftとEmacs Lispを有効化しています。Emacs Lispについては、あえて記述しなくとも最初から有効になっているため、書く必要はありません。

`org-babel` でSwiftを実行する

ここまでの設定を終えていれば、以下のように書くことで org-babel でSwiftを実行できます。

#+begin_src swift
let a: Int = 1
print(a)
#+end_src

#+RESULTS:
: 1

まとめ

実際にiPhone等で動作するアプリケーションを開発するためにはMacbookが必要になりますが、Swiftの基本的な文法は、Linux上でも十分に試すことができますし、 org-babel で気軽に試しながら勉強できるというのは大きなメリットになる人もいると思います。

少なくとも、私の場合には org-babel が使えるということと、Xcode Playgroundsよりも気軽に試すことができるということはメリットでありますので、しばらくこの環境で勉強しつつ、軌道に乗ってきたらMacbookで実際の開発作業に取り掛かってみようかと思います。

Git Submoduleを使っている環境で、 upload-pack: not our refエラーが発生した場合の修復方法

Wed, 08 Oct 2025 13:39:47 +0900

Debian GNU/Linux 13が公開されたのを機に、このブログのメンテナンスを進めようと思い、GitHubのリポジトリをローカルにクローンさせ、サブモジュールの中身を引っ張ってこようとしたところ、以下の様なエラーに遭遇してしまった。

$ git submodule update

出力されたエラーは以下の通り。

Cloning into '/home/sonohen/work/blog/blog/public'...
fatal: remote error: upload-pack: not our ref 35b4c8b0165369c2f92485e2b384bfc78827c75f
fatal: Fetched in submodule path './', but it did not contain 35b4c8b0165369c2f92485e2b384bfc78827c75f. Direct fetching of that commit failed.

これは前回、 public というサブモジュールを git commit しなかったことが原因であり、既に当時のマシンは手元にない。サブモジュールの commit hash をGitHub側と合わせる必要があるので、以下のような手当をした。

$ cd public
$ git fetch
$ git checkout <valid_commit_hash>

$ cd ../
$ git add public
$ git commit -m "Update submodule ref to valid commit"
$ git push

これで、事象自体は解決したはずである。

今後に向けて

以下のような deploy.sh を書いておくことで push し忘れを防止したいと考えている。

#!/bin/bash

# build site
hugo -D

# commit using git
cd public
msg="Rebuilding site `date`"
git add -A
git commit -m "$msg"
git push origin master
cd ../

# upload all site settings
git add -A
git commit -m "$msg"
git push origin master

クレカで貯金体質に！賢い利用で未来を変える３つの秘訣

Sun, 28 Sep 2025 00:00:00 +0900

この記事の背景と目的

前回、キャッシュレス決済を賢く使い、資産を増やす方法について私が実践している内容を記載しました。まだの方は、この記事よりも前に、こちらを読んでみてください。

その中で、以下に示すような費用は、クレジットカードで支払いをしているということを記載しました。

水道光熱費
自動車税
NHK受信料
火災・地震保険
ガソリン（※現在は近隣のガソリンスタンドがSuica支払いに対応したため、都度払いに移行）
高速（ETCカード）
高額決済（おおむね2万円以上）

この記事では、これらの支払いにクレジットカードを使っても、「支払いの都度、残高が減るという現金払いと同じメリットと、利便性というキャッシュレスのメリット」を適用するために、私が実践している内容をご紹介します。

使ったら、その日のうちに現金を取り分ける

使ったら、その日のうちに現金を取り分けておきます。つまり、使えるお金の中から、クレジットカードで支払った分だけを別にしておくということです。

ここで活用したいのが、「クレジットカードの利用通知」と、住信SBIネット銀行の「目的別口座」の2つです。

まず、クレジットカードの利用通知ですが、支払い先と金額がメールで送られてくるので、これは必ず使いましょう。不正利用の早期発見にもつながります。

カードご利用通知｜クレジットカードなら、JCBカード

次に「目的別口座」です。これは、クレジットカードで支払った分を、別の口座に取り分けておくために使います。私の場合は、普段使うお金は普通口座に入れておき、クレジットカードで使ったお金は、その日のうちに目的別口座（クレジットカード支出分口座）に移しています。その際、いくら移せば良いのかを決めるのに見ているのが、「クレジットカードの利用通知」です。

目的別口座 | 商品・サービス | NEOBANK 住信SBIネット銀行

私が参考にさせていただいている方の中には、封筒で取り分けているという方もいらっしゃいますので、お好きな方法を使えば良いのではないかと思います。

いずれにせよ、「使った分は、その日のうちに取り分けておく」というルールにより、現金払いのように使えるお金が減りつつ、キャッシュレスの利便性を享受することができます。

1週間に1回、確定した残高を繰上げ返済する

クレジットカードによっては、確定した明細を繰上げ返済することができるサービスがあります。私が知る限り、JCBカードと三井住友カードは、繰上げ返済の手続きをインターネットで実施できます。

これを活用し、1週間に1回、確定した明細分の支払いを、先ほど述べた「目的別口座」から繰上げ返済してしまいます。

私がこのようにしている理由は2つあります。

普通口座と目的別口座は、容易に資金の移動ができてしまう。つまり、普通残高が苦しくなってきた時に、目的別口座のお金を使い込んでしまう可能性が高くなる。1週間に1回でもカード会社にお金を支払ってしまえば、目的別口座の残高は少なくなるはずなので、使い込む金額は少なくて済む。
クレジットカードの残高が多いのは、プレッシャーになる可能性がある。クレジットカードの残高 = 借金であり、残高が少ければ少ないほど良いと考えているため、1週間に1回、前払いすることで残高を減らしたい（気分の問題）。

まとめ

クレジットカードでも、現金払いの良さとキャッシュレスの利便性を両立させることができます。その際に使うのは、「クレジットカードの利用通知」、「目的別口座を使った現金の取り分け」、「繰上げ返済」の3つです。

2回にわたって、キャッシュレスの利便性を求めながら、現金払いの良さも両立させることで資産を増やす方法として、私が実践していることを記事にしました。

基本は、デビットカードを基軸にした支払い方法を使いつつ、高額な支払いなどはクレジットカードを使って定期的に繰上げ返済するということで、私は賢く、キャッシュレス社会を生き抜こうとしています。

日々、よりよい方法を考えているところではあるので、今後もアップデートがあれば記事にしていきたいと思います。ご覧いただいてありがとうございました。

キャッシュレス決済の賢い使い方～支出管理と資産形成のコツ～

Sat, 06 Sep 2025 00:00:00 +0900

要約

キャッシュレス決済は便利ですが、使い方を間違えるとつい無駄遣いし、資産が増えにくくなることもあります。以下のポイントを参考にすると、利便性を享受しつつ資産を守ることができます。

主なキャッシュレス決済の種類

クレジットカード（後払い型）:　支払は月単位でまとまり、後日まとめて銀行口座から引き落とされます。便利ですが、使いすぎやすい面があります。
デビットカード（即時払い型）:　使った直後に銀行口座から即時引き落とし。支出管理がしやすく、現金感覚に近いのが特徴です。
チャージ式電子マネー:　あらかじめチャージした金額内での利用なので、使いすぎの心配がありません。

賢い使い分けの実例

高額決済や生活インフラの支払いには、クレジットカード
日常的な買い物や交通費、サブスクなどは、デビットカードや電子マネー

こうすることで、無駄遣いの抑制・日々の資産把握・家計の見える化を実現できます。

キャッシュレスをめぐる日本の最新動向

2024年のキャッシュレス決済比率は42.8%。デビットカードは3.1％と伸びていますが、全体ではまだ少数派です。
補償面ではクレジットカードの方が手厚い傾向がありますが、デビットカードもセキュリティや銀行ごとの工夫が広がっています。

私はキャッシュレス決済の使い分けにより、増えも減りもしなかった資産を、1年間で190万円近く増やすことに成功しました。この記事では、そのことを記載したいと思います。

キャッシュレス決済の種類

主なキャッシュレス決済には、以下の4つの種類があります。

後払い（例：クレジットカード）:　ある期間に使った金額を、決められた日にクレジットカード会社に支払う方法。請求をまとめられるメリットがあるものの、使いすぎる傾向にある。
都度払い③（例：デビットカード）:　支払いの都度、デビットカードに紐づけられている銀行口座から即時引き落としされる支払い方法。（即時引き落としされない場合もありますが、話が複雑になるため割愛）
都度払い④（例：モバイルSuica）:　支払いの都度、電子マネーの残高から即時引き落としされる支払い方法。クレジットカードやデビットカード、銀行口座、ATMや券売機などで電子マネーの残高にお金を入れ、その範囲内で使用できる。
後払い②（例：ペイディ）:　ある期間に使った金額を、決められた日に金融会社に支払う方法。クレジットカードと違う点は、与信審査が簡易であったり、利用限度額が一般にクレジットカードよりも低額に抑えられている点などです。「即買って、支払いは後日（Buy Now, Pay Later）」と表現されることもあり、別名、BNPLとも言われます。

この記事では、1〜3を「キャッシュレス決済」と扱います。

参考情報として、キャッシュレスの場合、現金に比べて支出が1.7倍程度増えるという調査結果があります。

キャッシュレスは、「お金を使いすぎてしまう」って本当？キャッシュレスは、「お金を使いすぎてしまう」って本当？｜ベネッセ教育情報サイト【ベネッセ｜教育費】消費税増税をきっかけに、キャッシュレス決済への流れが大きく加速しています。政府は2025年の大阪・関西 benesse.jp

日本クレジットカード協会の調査(2017年度)によると、支払いをクレジットカードで行う人は現金で行う人より1.7倍多く使うという結果でした。

使ってしまいがちな場面は、「衣料品専門店」「雑貨・文具」「タクシー」の支払いで、現金の２倍以上と高くなっています。共通するのは少し特別感のある消費場面です。

― ベネッセ, キャッシュレスは、「お金を使いすぎてしまう」って本当？

Before - 何でもかんでも、後払い

水道光熱費やサブスクリプションなどの固定費、食料品や飲食の立替などの変動費。全ての支払いを後払いで支払っていました。後払いでは支払った実感のない私は、常にクレジットカードの請求額が大きな金額になっており、給与や副業収入のほとんどがクレジットカードの支払いに回っている状態でした。何に金を使っているのかもよく分からない状態で、資産が増えることはありませんでした。

今思えば、クレジットカード会社の思う壺というか、いいカモだったと思います。便利で、ポイントも貯まるということで、わずかなポイントのために、大きな金額を浪費していたのです。

After - 後払いと都度払いをうまく使い分ける

今はどうしているかというと、以下のようにキャッシュレス決済の方法を使い分けています。ほぼ、現金主義と同じです。

水道光熱費、自動車税、NHK受信料、火災・地震保険、ガソリン、高速（ETCカード）、高額決済（おおむね2万円以上）は、後払い（クレジットカード；JCBカード）。
通勤や日常の移動に使っているモバイルSuicaは、都度払い（デビットカード；住信SBIネット銀行プラチナデビットカード）からチャージして利用。
サブスクリプションや、その他の日常的な決済は、都度払い（デビットカード、またはiD；住信SBIネット銀行プラチナデビットカード）。

こうすることのメリットはいくつもあります。要するに、「支払いの都度、残高が減るという現金払いのメリットと、利便性というキャッシュレスのメリットを両立できる」ということです。

常に現金が手元に残る:　私の場合、後払いの金額が（高額になったとしても）月に10万円を超えることはなく、クレジットカードの引き落としが終わっても、常に手元に現金が残る。
無駄遣いをしなくなる:　支払いのたびに銀行口座の残高がリアルタイムに減っていくため、その範囲内で支払いを考えるようになって無駄遣いをしなくなる。
資産の増減を日々確認できる:　支払いの大半を都度払いで行うことで、家計簿に使っているMoneyForwardというアプリで、ほぼリアルタイムに家計簿が作られる。後払い（クレジットカード）の場合には、利用から明細が上がるまでのタイムラグがあり、リアルタイムというわけにはいかない。これにより、資産の増減を毎日見ることになるので、無駄遣いをやめようという気持ちがより強くなる。

キャッシュレスの利点を損なうことはない

キャッシュレス決済のメリットの1つである迅速な支払いは保たれたまま、資産は増えていく。ポイント還元も、私が使っている住信SBIネット銀行のプラチナデビットカードであれば1.25%と、そこまで低くはありません。また、同カードは、ポイントが大体翌月の15日前後に付与され、設定次第では決済時にポイントが自動で充当されます。

まとめ

日本におけるキャッシュレス決済額のシェアは42.8%、そのうちデビットカードのシェアは2024年時点で3.1%（約4.4兆円）で、キャッシュレス決済額に占める割合としては少ないです。周りでも、不正利用があった場合の補償に不安があったり、そもそもデビットカードを認知していないケースがあったりします。

クレジットカードでうまく家計ができている人にとって、デビットカードを使うメリットはあまり多くないかもしれませんが、私のように「使った感覚が薄く、つい無駄遣いしがち」という人にとっては、デビットカードも含めたキャッシュレス決済方法の使い分けは、資産を増やす上で重要な考え方になるかもしれません。

クレジットカードとの上手な付き合い方もご紹介しています。ぜひ、本記事と合わせてご覧ください。

Apple Watch Ultra 2の先入観に惑わされながら、バンドの最適解がスポーツバンドであることを見落としていた日々

Fri, 05 Sep 2025 00:00:00 +0900

Apple Storeでは、3種類のバンドがApple Watch Ultra 2用として販売されている

私の「変な先入観」は、ここから始まったーー。

Apple Watch Ultra 2 Apple Watchのバンドを購入

Apple Watch Ultra 2を購入した際に付属していたのはブルーオーシャンバンド。その後、服装に合わせナチュラルチタニウムミナレーゼループ（長い……）を追加で購入しました。

バンドの質はいいんだけど、どこか着けづらい

あくまで「冒険する人のためのウォッチ」なので、バンドもそれに合わせて、外れにくいように、頑丈に作られているのです。ま、要は着けづらいということです。

オーシャンバンドは留め具がキツく作られているし、ミナレーゼループは幅広でジャキジャキする。買ったこともつけたこともないですが、アルパインループも着けづらいというレビューを見たことがあります（慣れ次第とも言われてました）。

「普段遣い」には、どうも適さないように思えていたのですが、先の先入観から別のバンドを試そうともあまり思わなかったのです。

スポーツバンドはどうだろう？

Apple Watch Journalのこちらの動画。Apple Watch Ultra 2にスポーツバンドをつけているのです。

この動画を見たときに、「あれ、Ultra 2にスポーツバンドいけるんじゃない？」と思い、ナチュラルチタニウムミナレーゼループを、自宅にあるApple Watch 10のスポーツバンドに換装したところ、

これは着けやすく、着け心地も快適だぞ！

となったのです。

割とこういうことは多いのではないか

変な先入観ってあると思います。色々な人がどのように使われているのかを見聞きすることで、それがきっかけで自分の考え方や行動が変わるのかもなあと思った経験でした。

私はITエンジニアですが、この出来事から色々な勉強会に出て見識を広げるのも重要だなと考えました。

NIFTY Tech Day 2025で思ったことと職場への持ち帰り

Fitbit Charge 6から、結局Apple Watch Ultra 2に戻った話

Sun, 24 Aug 2025 00:00:00 +0900

前回、Apple Watch Ultra 2を使うのをやめて、Fitbit Charge 6に移行した話を書きました。

それから2ヶ月経ち、今、腕に巻いているのはApple Watch Ultra 2なのでした。

戻った理由① スマホ無しで持ち出せるセルラーモデルは、なんだかんだで便利

ウォーキングが趣味で、多い時には週7日、少ない時でも週3日は時間をとって歩くようにしています。

その時に、スマホや家の鍵を持ち出すのは面倒だな、と思っています。

そこで活躍するのが、Apple Watchの中でも通信機能を持つセルラーモデルです。それなら、外にいても通信できます。音楽を聴くのも、家族に位置情報を知らせるのも、家の鍵を開け閉めするのもApple Watch単体でできるので、スマホも家の鍵も持ち出す必要はありません。

ウォーキング中におすすめなのが、Audible、Radiko、Apple Musicです。時間が溶けますよ。

戻った理由② アプリによるカスタマイズが便利

先に挙げたAudibleやRadikoもですが、Apple Watchはアプリによって自分好みにすることができます。

例えば、外出先でポイントカードを求められた時を思い浮かべます。財布を持っていなければ、ポイントを取り損ねます。

ですが、Apple WatchにMembership Widgetというアプリを入れ、事前に設定しておけば、財布がなくてもポイントを貯めることができるのです。

Membership widget

私は他にも、天気系（Yahooの天気、防災速報アプリ）、楽天Pay、日経、StepsApp（歩数をわかりやすく見せるアプリ）を入れています。

特に楽天Payは、楽天ポイントカードとQRコード決済の両方をApple Watchでできるようになったので便利です。

楽天ペイ

また数ヶ月後、Fitbitに戻ってたり、はたまた違うスマートウォッチに変えていたりするかもしれませんが、その時はその時でまた理由づけをしようと思います（笑）。

Apple Watch Ultra 2をやめて、Fitbit Charge 6にした話（前編 - 背景編）

Sun, 25 May 2025 00:00:00 +0900

先日、Apple Watch Ultra 2を秘書がわりに使っているということを記事にしました。

Apple Watch Ultra 2は快適に使っていましたが、先日困ったことがありました。ゴルフの練習中に、グローブとボタンが干渉してしまい、意図せず大量のスクリーンショットが撮影されてしまったのです。設定でスクリーンショットの生成を止められることは分かっていますが、場合によっては誤動作を引き起こす可能性もあり、少し不安を感じ始めました。

この経験から、Apple Watch Ultra 2の完成度について疑問を持つようになりました。Appleは開発者向けに、ゴルフコンパニオンとしてのApple Watchの機能を開発するためのAPIを公開（iPhone Mania）しています。にもかかわらず、グローブを装着して手首を曲げた際にボタンが干渉してしまうのは、Apple Watch Ultra 2自体の完成度としてどうなのかと疑問に思いました。（期待しすぎだったのかもしれません。）

Apple Watch Ultra 2の挙動とプロダクトの完成度に少し残念な思いをしたことで、以前のような熱量が冷めてしまったというのが正直なところです。

そもそも、Apple Watch Ultra 2が必要だったのか？問題

ガジェットは、必要性ももちろん大事ですが、ロマンはもっと大事だと思っていますので、買うときに必要性だけを考えないようにしている、というのが前提にあります。

その上で少し冷静になって、本当にApple Watch Ultra 2が必要だったのかを考えてみました。

私の主な用途は、以下の4つです。

予定とメッセージの通知
音声メモの収集
健康状態の収集
決済（モバイルSuicaとデビットカード（住信SBIデビットプラチナカード））

これらのために本当にApple Watch Ultra 2が必要なのか？と考えると、結構疑問なところがあります。音声メモの収集を除いて、他のスマートウォッチあるいはアクティビティトラッカーでできるからです。

また、Apple Watch Ultra 2は単独で4G通信ができます。iPhoneを持ち歩かなくても通信ができるので、極端な話、Apple Watch Ultra 2だけで外出してもなんとかなりそうな気さえします。が、実際に私が出歩く限りはiPhoneを持ち歩かないということはほとんどない（近所のコンビニに行く時くらい）なので、あってもなくてもどちらでもいいや、というくらいの価値です。

…さすがにApple Watch Ultra 2は高いのでは？と思い始めました。

音声メモをどうするか？

私が音声メモを取りたいと思うのは、手が離せない状況ではなく、思いつきをそのまま言葉として記録しておきたい場面です。つまり、言語化がうまくできるかどうかは分からないが、そのもどかしさも含めて記録しておきたい場面、です。

Apple Watch Ultra 2は、ほぼ24時間装着できた（充電の時間は除く）ので、ほぼ全てのそうした場面をカバーできていました。ゆえに、Apple Watch Ultra 2がなくなると困る場面は多々出てきます。

トイレ
風呂

といっても2つか……。これらの場面をどうやってカバーするかは、今後考えていかなければなりませんが、その他の場面においてはApple Watch Ultra 2が無くなっても問題はなさそうです。

他のApple製品との連携をどう考えるか？

Apple Watch Ultra 2と他のApple製品との連携で使われる（と思われる）のは、Handoff、AirPlayそしてiCloud連携です。そして、私が使っているのはAirPlay（AirPodsとの連携）と、iCloud連携（主にDrafts）です。

前者（AirPlay）は、Apple Watch Ultra 2にダウンロードしたAudibleやApple Musicのデータを、Apple Watch単独で、iPhoneを持ち歩かずに視聴するために使っています。iPhoneを持ち歩かない場面は少ないため、Apple Watch Ultra 2単独でAirPlayが使えなくなる影響はほとんどないと考えています。

後者（iCloud連携）は、Google Keepに移行すれば良いかなと思っています。Draftsをハブにしていろいろなアプリケーションにメモを飛ばす、というのがDraftsの目玉機能なのですが、私の場合は情報の一次収集場所くらいにしか使っていないので、Google Keepでも問題ないのです。

ですので、この辺りも特に問題にはならなそうです。

前編のまとめ

ゴルフの練習で感じたプロダクトとしての違和感で熱が冷め、冷静に用途を考えると、他のスマートウォッチ、アクティビティトラッカーでも十分代替できることがわかりました。

次の記事では、Apple Watch Ultra 2の後任として、なぜFitbit Charge 6を選んだのかを執筆したいと思います。

2025年8月24日追記

結局、Apple Watch Ultra 2に戻りました。

2025年9月6日追記

Apple Watch Ultra 2のバンドはスポーツバンドがいいよねという結論に至りました。

勉強会が仕事を変えてくれたという経験談

Tue, 29 Apr 2025 00:00:00 +0900

今年の2月に、ニフティ社の勉強会に参加したことを記事にしました。

この勉強会をきっかけに、社内勉強会への登壇回数を増やしました。その結果、予想以上の効果を実感したので共有します。

なお、私はシステムエンジニアの端くれのため、テーマはIT関連（特にAIやクラウド設計）が多いです。

効果1 アクティブラーニングによる理解促進・定着

「テーマを決め、資料を作り、理解が足りない部分は補足し、他者へ教授する」という一連の過程で、理解が進み、定着する効果は大きいものがありました。

例えば、「トランスフォーマーモデルの概要」をテーマにし、資料を作っている際に「自己注意機構（Self-attention mechanism）」というキーワードをきちんと説明できない自分がいました。一言で言えば、「文章における要素間の関係を捉えて文脈を理解するための仕組み」なのですが、これをわかるように平易に説明するのは難しいと感じています。

なんとか形にして迎えた勉強会当日、説明した内容を全ての聴講者が理解したかは不明ですが、少なくとも自分で資料にして説明するという過程で、自分なりの理解が進み、定着したのではと思います。

効果2 社内での認知度向上

普段はプロジェクトに閉じた範囲で物事が完結することが多かった私ですが、プロジェクト外の活動である勉強会を通じて、社内での認知度が上がった（社内での交流関係の幅と深さが増した）ように思います。

今まで接点のなかった人から「AI関連のプロジェクトで、AIも去ることながらクラウド設計の部分でも協力して欲しいことがあるんだけど」と声をかけていただいた（これをきっかけに仕事になりました）

以前、同じプロジェクトを担当していた先輩から「当時は技術力があるなぁという印象はなかったけど、かなり深いところまでやってるんだね」と声をかけていただいた

興味や腕に覚えのあることを自分から発信することで、社内での認知度が上がり、その結果として新しい仕事にチャレンジすることができていることを考えると、やはり自分から発信し、いろいろなチャンスを掴んでいくことが重要だなと認識しました。

効果3 仕事の幅の広がり

これはコツなのですが、勉強会では絶対に完璧を目指さない方が良いと思います。例えば、以下のような要素を残しておき、それを発表してしまう、ということです。

ここまでは理解できたけど、ここから先はよくわからなかった
この実装の課題はこうで、その解決策は思いついていない
実装中にトラブってこんなエラーが出たけど、実は解決できなかった
そもそも、自分に足りないところはこういうことだとわかった

そうすると、わかる人が教えてくれたり、たまたま参加していた人が他の部署の人に繋いでくれたり、研修の機会を提供してくれたりします。そして、そこで得た知識やノウハウは、また別の機会の勉強会で発表をしたり、他部署と連名で発表したりするのです。

私の場合は、当時の業務でできていないことを明確にしたことで、管理職が別部署に繋いでくれ、その部署の方にメンター役を担ってもらい業務をやり切っただけではなく、これから、その方と一緒に新しい仕事を始めようとしているところです。

勉強会において、「わからない」「できていない」を残すことは、強力な武器になり得ることを理解して取り組むことが重要だなと、私は思います。

まとめ

勉強会に登壇するようになって仕事の幅も人脈も広がり、「会社って意外と面白いもんだな」と思うようになりました。余計忙しくなった気もしますが、その分充実しているということで、結果オーライだと思っています。

そういう意味では、きっかけを与えてくださったニフティ社の方には感謝しています。

今は社内での発表に閉じていますが、今後は社外への発表もしてみたいと思っているので、まずは社外の勉強会に今以上に積極的に出てみて、どんな雰囲気なのかを知り、どういうことができるのかを知りたいと思います。

もし、私と同じような境遇を経た方で、今は社外に向けていろいろ発表してるよ、という方がいれば、どんなふうにして社外向け発表の最初の壁を乗り越えたのかなど、経験談を教えていただけると嬉しいです。

この3ヶ月で得た、仕事におけるAI活用と、人間の役割に関する重要な気づき

Mon, 24 Mar 2025 00:00:00 +0900

この記事の内容は、あくまで私個人の見解であると同時に、仕事内容の詳細までを書くことはできないので、抽象的かつ意味不明な記載があると思いますが、悪しからずご了承ください。ただの仕事の感想文です。

職業柄、数多のシステム開発プロジェクトに関わってきたが、それでも過去に扱ったことのない技術領域で、短期間でやり遂げなければならない仕事をやっていたのである。

今回はシステム開発ではなく調査業務であり、キャッチアップ、課題設定、仮説設定・検証などを経て、成果をどうにか納めることができた。

これができた理由は、以下の3つがあると考えている。

ピンポイントの技術の詳細は把握していないが、周辺に対する問題意識を常日頃から持っていた。
色々な局面で使えるフレームワークを持っていた。
AIエージェント（Perplexity.ai）が使える環境にあった。特に、初期のリサーチで大活躍した。

こう考えた時に、1.と2.は人間だけができる仕事なのかなと思ったので整理しておくことにした。

人間の役割

常日頃から問題意識を持つ

自分の周りの事柄に対して、「どうしてこういう仕組みになっているのだろうか？」、「なぜ、こうしたのか？」、「自分ならこうするのに」といった問題意識を持つ。そして、その事柄に対して興味を持ち、調べる。

こうしたことの積み重ねが、「詳しくは知らないけれども、なんとなくわかる」ことの引き出しを増やすことに繋がっていく。引き出しは、いつの間にか他の引き出しと繋がり、これが独自性につながっていく。

これにより、キャッチアップにかかる時間が短くなり、また、課題設定もどことなく的を射るようになってくる。要するに、仕事の成功率が高くなるのである。

考えてAIエージェントを導く

ただ考えるのではない。ある程度の縛り（枠）がないと考えることは難しい。例えば、「渋谷についてあなたの意見を述べてください」と言われても、ただただ困惑するのみではなかろうか。

今までに、多くの頭の良い人たちが考えるための縛り（枠）を考えてきており、それらをフレームワークという。

フレームワークのメリットには3つあると考えている。

考える前段階で、考えるための枠をゼロから考える必要がない
考え忘れが減る
フレームワークを用途に合わせて組み合わせることで、より思考がクリアになる

まず、適当にAIエージェントに質問を投げる。そうすると、ディープリサーチを行い、回答を作ってくる。もっともらしい回答を作ってくるのだが、そこに偏りや検討漏れがないかを、フレームワークに当てはめて考えていく。

偏りを補正しつつ、検討漏れの部分をさらに問うていく。この繰り返しで、生成された回答の質を高めていくのである。

まとめ

「生成AIを活用するには？」という言葉が散見されるように思う（私の周りだけ？）。やれ、動画作成にはXXだ、プレゼンテーション作成にはXXだ、といった具合である。

今や色々なツールにAIが組み込まれており、適材適所で使えた方が良いということに反対するつもりはないのだが、ツールを使いこなすために必要な土台に考えを巡らせなければいけないのではないかと思ったので、この記事を書いた。

AWS SysOps Administrator - Associate合格記

Sun, 16 Feb 2025 00:00:00 +0900

先月、AWS Certified Solutions Architect - Professionalに合格しました。こういうものは、連続して受験してしまうのが、記憶が新鮮なうちに対策ができるので有利なわけです。また、Solutions Architect - Professionalも余裕（844点）で合格していたので、Associate資格で残っているSysOps Administrator - Associate（以下SOA）は、それほど手こずらずに取得できると思ったのです。

ところがどっこい、正直、過去一難しかったです。Solutions Architect - Professionalの時よりも感触が悪く、マジで落ちたと思った。

受験前の状態

CLF, SAA, DVA, SAPPro取得済み（SAProは844点）
AWSが出しているサンプル問題は、SAPPro合格後、対策を始めた時点で100%正解。

試験中の感想

一問目から分からねぇ・・・。

試験結果

789点。以下の分野は「改善が必要」でした。

第一分野：モニタリング、ロギング、および修復
第四分野：セキュリティとコンプライアンス

何が良くなかったのか

最初から自信過剰になっていた

AWSが出しているサンプル問題で、対策前に全問正解した時点で、正直「何もしなくても受かるかも」と自信過剰になっていました。SOAは特に難しいと聞いたことがあるので、その認識をきちんと持った対策をすべきでした。

ハンズオンをしなかった

今回、問題集を使っていて分からないサービスがあった時には、ブラックベルトも読まず、ハンズオンもしませんでした。結果、理解があやふやなまま試験に突入しました。

次、どうしようか

Solutions Architect - Professionalまでは、自分なりに「AWSの裏側ってこんな感じになっているのかな」とかを調べながら勉強していたので理解が深まったように思えますし、それが点数にも繋がったのだと思います。

SOAは、試験に合格するための勉強をしてしまいました。悪いことではないのですが、AWSを生業にしている人間としては、試験に合格することよりも試験勉強を通じてAWSを理解することを目的とすべきであって、その点においては同じ時間を使うにしてもだいぶ勿体無かった気がしていますし、点数もギリギリになってしまいました。

次はDeveloper - Professionalを受験しようと思っていますが、少し時間を長めにとって、ハンズオンやブラックベルトを通してAWSの仕組みをもう少しきちんと理解するようにしてから試験に臨みたいと思いました。

終わりに

今回、半額になるバウチャーを使ったとはいえ、受験費用は11,000円でした。安くはない試験ですので、きちんと自信を持って取り組むことができるように準備はしたいものです。

これで、以下の資格を取り終えました。

AWS Certified Cloud Practitioner
AWS Certified Solutions Architect - Associate
AWS Certified Developer - Associate
AWS Certified SysOps Administrator - Associate
AWS Certified Solutions Architect - Professional

参加者として勉強会の定着率（学習効果）を最大化する方法を考えてみた

Tue, 11 Feb 2025 00:00:00 +0900

先日、NIFTY Tech Day 2025に参加しました。

その中で、学習方法によって定着率が変わるという「ラーニングピラミッド」の概念を知りました。せっかく参加した勉強会、定着率を上げたいと思いますよね？

あまり時間をかけず、定着率を上げるための方法を検討してみたので、共有させてください。

きっかけ

私は手書きでメモを取る派でした。いろいろな意見があると思いますが、私が考える手書きメモの最大のメリットは自由であることです。前後左右、自由に構造化できますし、関連を線で表現することもできます。

その一方で、分からない言葉が出てくると、スマホや辞書などを使って調べて、調べた結果をメモに書くことになります。この方法では、分からない言葉が多発してくる場合に、いささか不便です。

ふと思い浮かんだのは「マインドマップを使ってメモを取れば良いのでは？」というありきたりな考えです。手書きメモに近しい自由度で書くことができますし、分からない言葉はその場でAIに聞き、回答をマインドマップに反映することができます。

今回、勉強会中のメモは手書き、勉強会後のまとめにはNotionを使いました。分からない言葉は手書きメモに印をつけておき、NotionでまとめるときにNotion AIに聞きながら整理しました。AIを勉強会中に使えばもっと効率的、効果的だったのでは、と思いましたが、手書きメモ、およびマインドマップとAIの組み合わせでは、どちらの方が定着率が高まるのかが分からない状況でした。

定着率を高めるには（ラーニングピラミッドによる「他者への教授」）

そこで出てくるのがラーニングピラミッドです。学習方法によって定着率が変わるということを示すもので、定着率が低いもの、高いものにはそれぞれ以下があります（括弧内は定着率）。

定着率が低いもの　講義（5%）、読書（10%）、視聴覚（20%）
定着率が高いもの　グループ討論（70%）、実践・体験（75%）、他者への教授（90%）

勉強会は「講義」でしたので、これを「他者に教える」ところまで持っていくことが定着率を高める上で有効であると考えました。

とはいえとはいえ、時間がなければ機会もそう恵まれるものではない

とはいえとはいえ、の元ネタ。

勉強会に出るところまでが精一杯で、その後、内容を整理して、その上、人に教えている時間まではない、というのがほとんどではないでしょうか。私は、過去に何回も勉強会に参加したことはありますが、その場でメモを取る程度で、勉強会の後に整理し、さらに人に教える、ということはやったことがありませんでした。そのメモも、どこへ行ったかわかりません。

とはいえ、ラーニングピラミッドが示すように、人に教えるということの効果は無視できるものではありません。

まず考えたのは、人に教えるということです。会社の勉強会はあるにはありますが、スケジュールが微妙な時があります。それに、そもそも適した勉強会がなかったりします。そこで、「noteでもどこでも良いので、勉強会の内容をシェアするということをやってみてはどうだろうか？」ということです。インターネットであれば、時間の制約なくいつでも見てもらえるので、「人に教える」ことの代替手段になるのではないかと考えました。

ここでポイントになるのは、内容を整理するところにかかる時間をいかに短縮できるか、です。

まず、人に教えるためには自分が理解していなければいけません。勉強会終了時点で、自分の頭の中が構造化されており、不明な言葉がない状態になっていることが理想です。そのために最も重要なのは「勉強会中に分からないことを解消しておく」ことです。常にAIに触れるようにしておき、分からない言葉が出てきたらAIに調べてもらうのです。それでも分からないことは質問してみましょう。勉強会が終わるまでに内容を理解しておくことが大切です。

次に、すぐに共有できる状態にしておくということです。先ほど「noteでもどこでも良いので」と書きましたが、共有先はインターネットです。その際、扱いやすいデータは共有に使うプラットフォーム次第ではありますが、私の場合はnoteを使っているので、Markdown形式が最も扱いやすい形式です。note以外にも、NotionやGammaもMarkdownをサポートしています。

人に教えられるように理解したトピックを、Markdownのように自分が扱いやすいデータにしておく。これが時短しながら内容を整理するために必要なことだと考えます。

実例と改善点

メモをメモ帳で取る @ 勉強会中

今回

今回は、勉強会のメモを手書きで取りました。いくつか分からない言葉がありましたが、その言葉には後で調べられるように印をつけておきました。

今後

このプロセスは必要ありません。手書きでメモを取るということは、それをデジタル形式に変換する必要があるということで、その手間がかかります。今後は、はじめからマインドマップにメモを取ろうと考えています。これも後で整理する必要がある点で手書きメモと変わりませんが、コピペができる分、手間は省けます。

整理しながらNotionに転記する @ 勉強会後

今回

勉強会が終わった後、メモ帳に書いたメモをNotionに転記しました。後から見返してもわかるように記述すること、先に印をつけた言葉を調べました。この時に、Notion AIが大活躍しました。時間にして約1時間程度はかかりました。

復習にもなるので良いプロセスだとは思いますが、本質的には不要なプロセスです。なぜなら、メモを整形するという過程において定着率は上がらないからです。分かっているものを読んでも学習効果がないのと同じです。

今後

Miroのマインドマップでメモをとり、その裏で言葉をすぐに調べられるようにperplexity.aiでも動かすことにして、今後はこのプロセスは廃止したいと考えています。

Notionからnoteに転記する @ 勉強会後

今回

勉強会の情報は、タイトル、開催日時、場所、そして先にまとめた勉強会の内容をNotionに集約しています。今後も、この取り組みは続けていきたいと思っています。

今後

今後は、勉強会ごとに作ったマインドマップをNotionに取り込んでおくことにしたいと思います。

そして、マインドマップをもとにnoteに掲載する記事を執筆します。このプロセスは、自分用のメモから、人に教えるための記事を起こすことになるので、読みやすく、わかりやすく記載する必要があります。このプロセスは脳を活性化しますので、定着率の向上に貢献します。しかし、マインドマップであらかじめ視覚的に構造化していますので、まっさらな状態から記事を起こすよりも時間はかかりません。

ここで書いた記事は、noteに掲載します。Notionにまとめている勉強会の情報には、noteのURLも記載しておきます。こうすることで、自分用のメモと、人への共有に使った記事の両方が勉強会の情報から参照できるようになります。

NotionからGammaに転記する @ 勉強会後

今回

noteの記事をGammaにコピペすれば、ある程度の形になってプレゼンテーション用の資料が作られました。適当に手直しをし、保存しておきます。Gammaの共有リンクを、Notionに記録している勉強会の情報に追記しておきます。

終わりに

今回書いていて思いましたが、マインドマップでメモをとるということは、マインドマップの外にある情報（過去のマインドマップ）とリンクを直接的に取る方法がない、ということになります。この点、メモはトピックを超えて相互参照しやすいというメリットはありそうです。この点をどう運用するかは今後考えなくてはと思いました。

そもそも思いましたが、勉強会中にパソコンを立ち上げていると、後ろの人から覗き見されて「そんなことメモしてるのかよ」と思われそうだなと思いました。

参考

手書きメモの一部。これをMarkdownに変換するのは結構めんどい。

この記事のマインドマップ。このように構造化し、関連を線で表現すれば手書きメモ並の自由度は得られそう。

手書きメモをMarkdownに変換し、それをGammaでスライドに変換したもの

NIFTY Tech Day 2025で思ったことと職場への持ち帰り

Sun, 09 Feb 2025 00:00:00 +0900

2025年が始まってもう1ヶ月が経過しましたが、皆さんはもう勉強会やセミナーには参加していますか？

私は年初に「個人として毎月1回以上、勉強会に参加する」という目標を立てました。そして、NIFTY Tech Day 2025が今年初めての参加でした。参加によって刺激を受け、インターネットに学んだことをアウトプットすることも目標に加わりました。

ここでは私の感想と、職場への持ち帰りと実践をどう考えているかを記述したいと思います。

勉強会の学習効果を高めるにはどうしたらよいかを考えてみました。こちらも参考にしていただけると嬉しいです。

この勉強会を機に、自身も勉強会に登壇するようになりました。その結果、仕事が大きく変わったので、その経験談を書いてみました。こちらも参考にしていただけると嬉しいです。

AIと協働する次世代開発スタイル - 求められる新たなスキルと役割の変化

AIと人間が協働するステージには3段階がありますが、現在最も高度とされるのは「エージェント型AIとの協働」です。エディタに生成AIが組み込まれるようになったことで、以下の3つの形態で進化してきました。

文脈を理解し、適切なプログラムコードを補完する「自動補完型」
プロンプトを通じて対話形式でコードを生成する「対話型」
目的達成のために必要な作業を実行する「エージェント型」

一部（社内）では「生成AIによってシステムエンジニアの仕事が減少する」という意見もありますが、私はむしろ「やるべきことが増え、専門性が一層求められるようになった」と考えています。その理由は、生成AIの性能向上に伴い、人間がAIの生成物をレビュー・承認する作業の難易度が高まっているからです。このプロセスでは、必ず人間がボトルネックになります。

生成AIを効果的に活用するためには、レビューしやすい出力を得られるようAIをコントロールするスキルが求められます。また、レビューには知識が必要であり、そのためにカバーすべき領域が広がることや、チームで協力して対応する重要性も増しています。

こうした状況を踏まえると、「オープンソースの知識を深く持つ優秀な人材がチームに加わり、その生成能力で他メンバーに影響を与えている」という現実を、いかにコントロールして良い方向へ導くかが課題になると感じており、対応が必要だと認識しています。

さらに、「インナーソース」という概念は初めて知りました。これは企業内でオープンソース活動を展開する取り組みです。生成AIがプロプライエタリなソースコードではなく、オープンソースコミュニティの成果物から学習しているという事実に基づくと、オープンソースコミュニティの流儀やスタンダードを組織内に取り入れるかどうかが、生産性向上の鍵となる可能性があります。

エンジニアの殻を破る：インナーソースと社外活動がもたらした成長

「インナーソース」をニフティ社内で展開した功労者の方による講演でした。この取り組みはエンジニアだけでなく、ビジネス部門も巻き込み、ビジネス部門のメンバーがシステム設定ファイルの一部をプルリクエストで更新できる仕組みも構築したとのことです。また、次のトピックでも触れられていましたが、「将来的にメリットが学習コストを上回るなら、学習してもらう」という姿勢は非常に参考になると感じました。

特に印象的だったのは、「社外活動は話を聞くところから始めよう。社外の勉強会に参加し、アウトプットしていこう」というメッセージです。講演者自身も、インナーソースについては勉強会への参加からスタートし、人脈を広げていったと語っていました。この姿勢を見習い、自分も積極的に行動しなければと感じました。

自社製CMSからの脱却：10件のWebサイト再構築に学ぶ運用重視の技術選定

レガシーシステムの更新を組織課題として捉え、将来を見据えたアーキテクチャ設計と必要な教育を実施した結果、過去に何度も失敗してきた切り替えに成功したとのことです。プロトタイプを作成しながら設計を改善し、最終的には運用面も含めて高評価を得る設計に仕上げたそうです。

また、更新前のシステムと比較してリードタイムが短縮され、新規サイトの投入スピードも向上したため、IT部門とビジネス部門の双方にメリットがあったようです。

さらに、コンポーネント名の統一によって、生成AIが設計意図を正確に理解し対応できるようになった点も興味深いポイントです。特に詳細設計では、明確な目的意識を持った設計が重要であることが改めて示されました。

スクラムマスター入門者のための学習マップ効果的な学びと実践

スクラム開発を経験したと口にしながらも、「複雑なものへの対応」の仕組みについては知らなかったことに改めて気づきました。私が経験したのは、仕様が明確に定まらないためにウォーターフォールではなくスクラムを採用したというケースでした。

実際、スクラムには「技術・実装」「プロダクトとビジネス」「人と組織」「改善」の4つの象限が存在し、これらは独立しているのではなく互いに重なり合っています。それぞれ、開発者、スクラムマスター、プロダクトオーナーといった各役割が注目すべきポイントも異なります。

これまで自分が抱いていたスクラムマスター像とは異なる面があり、より深く学ぶほどにその役割の奥深さと面白さに気付かされました。

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップに書いてありますが「組織改革に立ち向かうあなたに知恵と勇気を与えます」とあるとおり、開発自体の話ではなく、もっと広い範囲の話であると認識しました。無知は恐ろしいと改めて思い、また興味があるのでもっと調べてみようと思います。と思っていたら、野中先生も本を書いていらっしゃる。アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

学びを文化に変える〜ニフティの内製研修と継続的成長の仕組み〜

ラーニングピラミッドの中でも、学習定着率が高いとされるアクティブラーニング（「グループ討論」「実践・体験」「他者に教える」）を、ニフティ社内の内製研修で実践しているとのことです。特に興味深かったのは、研修の参加方式として「オプトアウト方式」を採用した点です。これは、研修を基本的に「参加」とし、「欠席」の場合のみ事務局に連絡する仕組みで、この変更により参加率が1割から7割にまで向上したそうです。

私自身もアクティブラーニングを社内勉強会で活用してみたいと感じました。また、社内勉強会を高度化させることに抵抗がある人に向けては、社内ブログのようなプラットフォームを構築するのも面白いアイデアだと思いました。これにより、後から情報を検索しやすくなるだけでなく、講師役を避けたい人にも知識共有の選択肢を提供できるのではないかと考えています。

社内SEとしての進化：AIツールを活かすネットワークエンジニアの新たな挑戦

エンジニア不足の話は私もよく耳にしますが、セシール社でも同様に人手が足りない中で、業務効率の低下やコミュニケーションの課題、セキュリティリスクの増加といった問題を抱えているとのことです。これらの課題に対して、情シス部門の規模に適した形で解決策を模索していく必要があると感じました。

具体的には、ナレッジマネジメントを活用して「人に聞く頻度」を減らす効率化や、紙運用を削減するためのAI-OCR導入、さらにセキュリティログ監視へのAI活用などが挙げられていました。事業会社のIT部門にはこうした多岐にわたる取り組みが求められ、大きなやりがいがあると感じながらお話を拝聴しました。

終わりに

大変貴重なお話をお伺いさせていただいたと思っています。また来年も、ぜひ参加させていただければと思いました。

後日追記

勉強会での学習効果を最大化する方法を考えました。

Apple Watch Ultra 2で思考と行動が整理できた話

Sun, 26 Jan 2025 00:00:00 +0900

ある程度、Apple Watchの使い方に慣れている方を対象にしています。

思考と行動の関係と本記事の結論

前提である「思考と行動の関係」を整理したいと思います。人それぞれ色々な考え方があると思いますが、私が考える思考と行動の理想的な関係は以下の図に示すものです。

このように「思考と行動の間に2つの袋を置くことで、思考と行動はスムーズに連係する」というのが私の考え方です。それぞれの袋をわかりやすく表現すると以下のようになります。

忘れないための袋:　メモアプリ（Draftsなど）
行動するための袋:　カレンダーアプリ、リマインダーアプリなど

本記事が最も言いたいことは、以下の3点です。

2つの袋は、完全にデジタル化する。
「忘れないための袋」はDraftで管理し、取りこぼしなく集約するために、Apple Watch Ultra 2から音声入力で情報を記録する。
「行動するための袋」は、情報の種類に応じてカレンダー/リマインダー/Notion/今日の支出で管理し、「忘れない袋」を定期的に確認してそれらに移す。

以下で詳細を示します。

2つの袋は整理されていなかった

まず、2つの袋は管理されていませんでした。具体的には以下の状態でした。

忘れないための袋　Moleskine、Onenote、Notion、付箋紙、iPhoneのメモ
行動するための袋　Google Calendar、iCloud Calendar、紙のカレンダー、付箋紙、iPhoneのリマインダー、Todoist、Omni Focusなど

こうした状況でも、仕事や日常生活に支障は出ていませんでした。散らばっていても、その様は本人が一番よくわかっているということです。一番の問題は、「やりたいことができなくなっていた」ことです。情報が散らばっていると、情報の格納と検索で脳が疲労状態になります。そうすると、何をすれば良いのかが段々とわからなくなってきます。夢やビジョン、趣味に向かって計画し、実行できている実感が薄れてきます。

今まで、何度かこうした管理を徹底してきましたが、少し油断すると上記のような状態になってしまうのが常でした。改善しなければと考えていた時、Apple Watch Ultra 2のアクションボタンのことを思い出しました。「うまく活用できれば、思考と行動の理想形を実現できるのではないか」と考え、Apple Watch Ultra 2を購入し、改善に取り組みました。

改善後

それぞれ、以下のように整理をしました。

忘れないための袋:　Draftsに音声入力する。
行動するための袋:　Draftsに登録されたメモを識別・分類し、予定はGoogle Calendar、タスクはリマインダー、メモはNotion、支出は今日の予算に登録する。

実現できた理由はApple Watch Ultra 2によるものが大きかった

これが実現できた理由には、大きく直接的な理由と間接的な理由の2つがあります。

まず、直接的な理由はApple Watch Ultra 2を購入したことです。画面サイズが大きく、処理性能が高いので、ショートカットやアプリを画面上に多く配置できたり、音声入力の精度やアプリの起動速度に不足はありません。

次に、間接的な理由で、これには2つあります。

1つがリモートワーク環境になったことです。これにより、仕事中でも音声入力ができるようになりました。同僚から予定が送られてきても、Draftsに音声で予定の情報を入れておけば良いのです。

もう1つが、Siriやアプリを活用しやすくなったことです。これはApple Watch Ultra 2の画面サイズや処理性能の高さに関連するものですが、音声認識が速くなったことでSiriが使いやすくなっていますし、アプリに関しては文字が見やすくなったり、起動速度も申し分ありません。

そして、Apple Watch Ultra 2のアクションボタンです。物理的なボタンが具備されており、それを押下すると、あらかじめ設定したアプリが起動します。私はこれにDraftsを起動するショートカットを割り当てています。起動する敷居が高いもの（ネガティブ感のあるもの：お金や体重管理など）をアクションボタンに割り当てると、そうしたものも管理しやすくなるかもしれません。私は、Apple Watch 10も所有していますが、物理ボタンの利便性は極めて高いです。

ワークフロー

ここでは、私が試し、改良しているワークフローを紹介します。

思考で得た情報は、まず1つの袋に入れる

2つの重要なこと

1つは、自分に降りかかってくる情報に対して、反応的な行動をしないことです。スマホを見ていると、通知が多く送られてきます。それに反応しているうちに1日が終わってしまった、ということもあるのではないかと思います。通知を受けて即、行動しなければならないものはほとんどなく、いちいち反応していては時間がいくらあっても足りません。まずは、情報を「忘れないための袋」に入れ、対応は後で考えるということを原則にした方が良いと考えています。

もう1つは、分類しないことです。ここでの目的は、とにかく全ての情報を1つの袋に入れることです。情報の分類は脳の負担が大きい行為です。これをしてしまうと、1つの袋に情報を入れることが面倒になり、やらなくなります。そうして待っているのは、管理不能な状態で、日常に追われる毎日です。

「忘れないための袋」に情報を格納する

ここでは、Draftsというアプリを使います。このアプリのコンプリケーションをApple Watchのフェイス画面に設定します。そして、これをタップすると、すぐに音声入力ができる状態になります。

使い方は以下のサイトに詳しく書いてありますので、ご参考になさってください。

すべてのメモの入り口を「Drafts」にすれば迷いがなくなる

「忘れないための袋」に入っている情報は、定期的に識別・分類し、別の袋に移すか捨てる

この時点で、「忘れないための袋」に入っている情報は玉石混合です。これらの情報が何なのかを識別し、適切な場所に移します。例えば、「2月25日17:00　山田さんと打ち合わせ」という情報が入っていたとすると、これは予定に分類できます。このほかに、私は以下の4つに分類しています。

予定
タスク
残しておくべき価値のあるメモ
支出

個人的な感覚として、これ以上増えると利用するツールが増えてしまうので、5つくらいまでに押さえておいた方が良いのではないかと思います。

そして、分類ごとにツールを選びます。私の場合は、予定は「Google Calendar」、タスクの場合は「リマインダー」、残しておくべき価値のあるメモは「Notion」、支出は「今日の予算」で管理していますので、Draftsからそれぞれのツールに転記していきます。

このように、全ての情報は「忘れないための袋」（Drafts）に格納した後、識別・分類し、予定/タスク/残しておくべき価値のあるメモ/支出は、「実行するための袋」（Google Calendar/リマインダー/Notion/今日の予算）に格納され、維持していくことが重要です。

さらに、タスクについては、リマインダーの中にinboxという、何も整理されていないタスクを入れる場所を作っています。それらのタスクは、GTD（Getting Things Done）というメソッドを使って管理しています。詳細を知りたい方は以下のサイトを参考にするとわかりやすいと思います。

コツ

「忘れないための袋」から「実行するための袋」に移す敷居を下げる　タスクの場合は「インボックス」など、何でも受け入れる袋を作っておくと、まずはそこに移せば良いことになるのでおすすめ。

面倒でも毎日、袋分けをする　量が増えると手がつけにくくなり、管理不能になる。

同時に複数のツールを使わない　例えば、カレンダーにGoogle Calendarを使うと決めたら、しばらくはそれを使い、他のカレンダーツールは使わない。どっちに書いたかわからなくなり、情報が分散してしまうため。完全に移行する場合なら大丈夫ですが、同種のツールを並行して使うのは絶対にやめた方が良いです。

体系的に整理されたものを学ぶ　GTDは、結構前から整理されたタスクの管理手法なので、それを学ぶことで自分のやり方にカスタマイズしていくと運用がうまく回るようになる。

後から検索できる、そしてApple Watchなどに通知されるツールを使う　可能な限りデジタル化することが望ましい。アナログの場合は、検索や通知の面でデジタルに劣るため。

この結果、2025年にどのような成果を得たか

2025年1月から2月23日までの成果です。

以下の資格を取得しました。
- AWS Solutions Architect Professional - Professional（2025年1月）※2024年12月頃から勉強してました。2025年1月の勉強計画は、この記事の方法で対応したということで記載しています。
- AWS SysOps Administrator - Associate（2025年2月）
18冊の本を読みました。
縁あって、4月から念願だった大学院（MBA）に単科生として通うことになりました。

これらは、日常のごちゃごちゃしたものを整理し、やりたいと思っていたことにリソースを使うことができるようになったからに他なりません。

よかった点

2つあります。

1つは仕組み化ができたことにあります。これによって、情報の取りこぼしがなくなり、情報がどこに格納されているのかも把握された状態になるため、自信につながりました。また、物事を忘れなくなりました。厳密にいうと、自身の脳ではなく外部の脳が記憶し、後から探すことができる状態になっている、あるいは必要な時に通知される状態になっています。

もう1つは、やらないことが増えた点です。思考は、「忘れないための袋」と「実行するための袋」を経て、実行されることになります。その過程で、意味不明なタスクやメモなどを消すようにしたため、残ったものは確実に実行できるもの、そして価値があるものになります。その結果として、1つのことに投下できる資源が増え、質が上がり、短時間でも大きな成果を出すことができたと考えています。

改善したい点

3つあります。

1つは、袋間の移動を手動にしている点を省力化したいと考えています。手作業で行うと、作業ステップが増えるため、間違えたり、そもそもが面倒になったりします。Draftsのプレミアムプランに申し込めば「アクション」というものが使えるため、それを使って省力化できないかと考えています。

次に、音声入力できない場面での対応です。音声で入力できない局面はどうしてもあります（電車や職場など）。そうした場面で、効率よく、取りこぼしなくメモが取得できないかを考えたいと思っています。

最後に、アナログとの統合です。以下の記事でも書きましたが、マインドマップを使う方法によっても、なおアナログの利点には敵わないと考えています。アナログメモをどう扱うかはよくよく検討する必要があります。

AWS Solutions Architect - Professional合格記

Sun, 26 Jan 2025 00:00:00 +0900

対象としている読者の方

受験対策中のITエンジニアの方で，私と同じく「何をどこまでやればよいのかが分からない状態」で，不安に思っている。
自分が合格水準にあるのか，受験日を決めるために目安を知りたいと思っている。

執筆者の経歴

システムインテグレータ所属のSEです。AWS関連の認定は以下の通り受けています。

AWS Certified Cloud Practitioner, 799点（2021年）
AWS Certified Solutions Architect - Associate, 822点（2022年）
AWS Certified Developer - Associate, 834点（2023年）
AWS Certified Solutions Architect - Professional, 844点（2025年）

実務ではAWSを検証に使用しており，また，個人プロジェクトでもAWSを使っています。

好きなAWSサービスはAWS CDKです。

免責事項

この記事は，無償/有償部分問わず，私の経験や理解を記載したものであり，合格や正確性を保証するものではありません。最終的には，AWS公式ドキュメント等をご確認いただき，ご自身でご判断いただくようにお願いいたします。

勉強の順番

私は以下の順番で教材を勉強しました。どの教材も，受験にあたっては必須だと思いました。今回，Blackbeltは参照しませんでした（Associate試験のときにだいぶ読み込んだので、大丈夫だろうという驕りがありました）。

『AWS認定ソリューションアーキテクト－プロフェッショナル　試験特性から導き出した演習問題と詳細解説』
AWS Certified Solutions Architect - Professional (SAP-C02) 試験問題サンプル
AWS公式模擬試験
問題集①「2024年版！最新のソリューションアーキテクトプロフェッショナル試験に対応した模擬問題集です。同じ出題形式の本番レベルの問題と，参考URLを含む詳細な解説で構成されており，効率的に確実合格を目指すことのできる問題集です」(Clouds Starterさま)
問題集②「AWS認定ソリューションアーキテクト - プロフェッショナル(SAP-C02)試験対策の決定版！」(Maruchin Techさま）

勉強方法

事前に

『科学的根拠に基づく最高の勉強法』（安川康介著，KADOKAWA）を読み，効率的な勉強方法を学ぶことをおすすめします。私の場合，この本の方法で暗記物は時短できました。

本を2周し，必要な知識をたたき込む

『AWS認定ソリューションアーキテクト－プロフェッショナル　試験特性から導き出した演習問題と詳細解説』を読み，章末問題，および模擬問題を解きます。章末問題，模擬問題は最低，2周は解きます（1周目は誤答の洗い出し，2周目は1周目の復習効果の確認）。

現在の実力を知る

現在の実力を把握しておきます。

試験問題サンプル（5割を越えたら2週間後に試験日を設定）
公式模擬試験（8割を越えたら1週間後に試験日を設定）

勉強期間中に，定期的にこれらに取り組みます。私の場合は，1週間に1回取り組み，試験問題サンプルが5割を越えたら2週間後に，公式模擬試験で8割を越えたら1週間後に試験日を設定することにしました。

演習と知識獲得

ここからは，演習と知識獲得を繰り返します。

問題集①を1周する。間違えた問題を中心に復習する。
問題集①を試験分野ごとに全問解き直す。この段階では，誤答が多いと思います。1問に時間がかかるので，1回あたりの負荷を減らすために試験分野ごとの解き直しをしました。

試験分野ごとの正答率が7-8割に達したら，次に進みます。

問題集②Practice Test No.1とNo.2を2周する。間違えた問題を中心に復習する。復習後，間違えた問題のみ回答する。Udemyには間違えた問題のみを解答する機能は無いので，Excelで管理します。
問題集②Practice Test No.3～No.5を1周する。間違えた問題を中心に復習する。復習後，間違えた問題のみ回答します。

間違えた問題のなかで正答率が8割に達したら，次に進みます。

試験問題サンプルを解く。

公式模擬試験を解く。両者とも8割に達していれば，合格を狙うことができる水準に達していると思います。

重点的に学習した方がよいと思われるポイント

特に重要なサービスについて，押さえておいたほうがいい部分やユースケースなどを考えながら覚えた箇所について，私の覚え方をご紹介します。

ここまでの対策を行っていれば自ずと導き出されるポイントです。ご参考までに。

★★★★★（超重要）

Solutions Architect - Professionalで頻出のサービスのため超重要であると考えています。

PrivateLinkの構成サービス提供側の構成（リソース - NLB - エンドポイントサービス）と，それに接続する側の構成（リソース - インタフェース型VPCエンドポイント），および接続承認の方法（自動か手動）を把握しておきます。
Transfer Familyの種類，接続方法，ストレージの種類オンプレミスで構築，運用しているSFTPサーバを，AWS Transfer Familyを使って移行する場合に，接続元の機器や運用に変更を与えないようにするためにはどのように構築したらよいかを考えます。AWSに自社のIPアドレス範囲を持ち込み（BYOIP），BYOIPプールからElastic IPを作るという方法を考える必要があります。
Direct Connectの接続ルートと，仮想インタフェースの使い分けオンプレミスに設置するCustomer Gatewayから，Direct Connect LocationのCustomer Router，Direct Connect Routerを経てAWSに接続するルート，およびDirect Connect Routerから先のPrivate VIF(Virtual Interface)，Public VIF，Transit VIFのそれぞれの向き先を把握しておきます。関連して，Site-to-Site VPNでTransit GatewayやVPCに直接接続する方法も覚えておきます。これらは必ず絵に描けるようにしておくようにします。
また，地味ですがオンプレミスからS3等にアクセスする際に，ゲートウェイ型VPCエンドポイントは利用できず，インタフェース型VPCエンドポイントが利用できるのはなぜだか確認しておいたほうがよいです。前者はトラフィックをルートテーブルで制御，後者はENIで制御しており，VPC内部の名前解決を利用しています。ですので，インタフェース型VPCエンドポイントのみ，オンプレミスからアクセスできるのです。また，オンプレミスからインタフェース型VPCエンドポイントを経由してS3等にアクセスする場合，VPCのEnableDNSHostNamesとEnableDNSSupportの有効化が必要です。実態はPrivate Linkなので，Private Linkを使う場合にもそれらのオプションを有効化しておく必要があります。
VPC内のリソースからオンプレミスサーバの名前解決を行う方法，またその逆Route 53 ResolverによるDNSリクエストのフォワーディングルール，アウトバウンドエンドポイントの設置などを把握しておきます。これも絵を描けるようにしておきます。
Active DirectoryまわりSimple AD，AD Connector，AWS Managed Microsoft ADのユースケースを押さえておきます。対応しているサービス，MFAの要否，シングル vs マルチドメイン，フォレスト構築の要否によって使い分けを行います。また，AD Connectorはサブネットに配置するので，冗長化構成を取る必要があるのかないのかをよく考える必要があります。
移行系ツールの使い分けMigration Hub，Migration Evaluator，Application Discovery Serviceなど。

AWS Organizations周りについて、以下をよく把握しておきます。

SCPの目的と割り当て，タグポリシーの有効化，および必須タグをつけていないインスタンスをSCPで起動させないようにする方法
OUを分割し，元々のOUにいたメンバを新しいOUに持って行く際のオペレーションの方法
3つのガードレール（予防的・検知的・プロアクティブ）と実現方法（SCP・Config・CloudFormation Hooks）
Reserved Instanceの共有をオフにする方法（各OUに購入を許可していても，共有設定は組織の管理アカウントで行う必要がある）
AWS Resource Access Manager(RAM)で共有できるリソースには何があるか。

★★★（重要）

Solutions Architect - Associateでも問われる内容ですが，もう少し深い理解が求められます。

Route 53のルーティングポリシー混乱せずに覚える必要があります。特に3つのルーティング方式（位置情報ルーティング/地理的近接性ルーティング/レイテンシルーティング）は，特性を覚え，使い分けができるようにしておくことが重要です。
トラフィック課金の範囲リージョン間，AZ間，AWS内から外への通信は課金されますが，PrivateLinkとTransit Gatewayを使った同一リージョン内のAZ間通信の場合は，それぞれ時間単位料金とデータ処理料金の課金が行われます。
CloudFrontを媒介してオリジンにアクセスする経路でLamdbaを使うパターンとCloudFront Functionsを使うパターンではどう違うかビューワーリクエスト，オリジンリクエスト，オリジンレスポンス，ビューワーレスポンス。CloudFront FunctionsではHTTPヘッダの書き換えが可能。Lambdaは，ユーザが送信した画像をリサイズしてS3に格納する場合などに使います。
CloudFrontのフィールドレベル暗号化が必要になるユースケースと，RSA公開鍵・秘密鍵の紐付け先EKS等で，特定のPodのみがユーザから送信されたデータを参照できるようにするユースケースが想定されます。RSA公開鍵をCloudFrontに紐付け，公開鍵で暗号化。復号するオリジン側に秘密鍵を紐付けます。
ELBのターゲットグループとしてのIPアドレスタイプのユースケースus-west-1にアプリケーションをデプロイしている。日本にサービスを展開するにあたって，ap-northeast-1に同じアプリケーションをデプロイせず，コストを削減したいとします。このような場合に，ELBへの着信トラフィックの向き先をus-west-1のELBに向けるのがIPアドレスタイプのユースケースの1つです。
VPCまたはサブネットのCIDRが重複している場合の対応方法再設計，Private Linkを使って接続，NAT変換によって接続，セカンダリVPCを通す方法の4つがあります。
フェイルオーバーの方式の違いCloudFrontのオリジンフェイルオーバー，Route53のフェイルオーバールーティング，ELBのフェイルオーバーのユースケースの違いを押さえておく必要があります。関連して，Elastic IPのスワップ，4つのDR戦略（バックアップ・リストア，パイロットライト，ウォームスタンバイ，マルチサイト）の違いも押さえたほうがよいです。

★（そこそこ重要）

覚えればよいだけのものをここにまとめました。

クロスアカウントの実装方法
EC2/Lambda/Fargate/SageMakerの割引プラン。Reserved InstanceとSavings Planの違い
AppStream2.0のフリートの種類，インスタンスタイプ，スケーリングポリシー
VPCプレフィックスのユースケース
FSx for LustreとS3を組み合わせた遅延ローディングのユースケース
API Gateway REST APIで連携可能なAWSサービス

Grand Seikoを買った

Sun, 14 May 2023 14:43:18 +0000

セイコー社を信頼している

思えば、セイコー社との付き合いは長い。成人のときに購入してもらったセイコー5（7S26）、就職祝いに購入してもらったクロノグラフ（7T62）。いずれも10年以上使っている。

さすがに調整もかねて修理に出さねばと思っていたが、どこに依頼するかとは思案のしどころであった。近所に時計店は無いうえ、節目節目での大事な時計であるがゆえ、大手家電量販店の時計修理に出すのも気が引ける。なぜなら、彼らは時計専門では無いからであり、結局取次だろう。どこに取り次がれるのか分からないあたり、聞けば教えてくれるのだろうが不安ではある。しからば、セイコー社に修理してもらおうと思った次第である。

さすがに10年を過ぎた時計なので、修理ができないか、できるにしても高額になるだろうと予想していたが、それはいい意味で裏切られた。クロノグラフは全体的な修理・調整を依頼して約2万円。セイコー5は今、オーバーホールに出しているがバンドを新品に交換して約1万円。さすがにオーバーホールには時間がかかり、またバンドの手配に時間を要していることから2か月程度時間がかかっているが、クロノグラフのクォーツは2週間程度で修理・調整してくれた。10年を超えても、普通に修理してくれるあたりさすがだと思う。

サンプル数2であるが、こういう経緯があって、私はセイコー社のアフターサービスを信頼している。ほかのメーカーも同じなのかも知れないが、私は修理までしてもらったことはないのでよくわからない。

そしてGrand Seikoへ

いずれ、「きちんとした」腕時計が欲しいと思っていた。「きちんとした」というのの私なりの定義はこんなところである。

3針であること。
駆動方式は機械式であること。理想は、自動巻きではなく手巻きで、ノンデイトであること。
煌びやかでなく、目立たないこと。
製造工程が可視化されていること（工場を見ようと思えば見学できること）。
修理の体制が整っていて、長く使えること。
大きくとも直径40mm以内であること。
国産であること。

日本にはセイコー社のほかに、シチズン時計社やオリエント時計社といった時計メーカーがあるが、あいにくそれらのメーカーの時計を購入し、修理までを受けた経験はなかった。シチズン時計社のザ・シチズンや、オリエント時計社のメカニカルムーンフェイズ等は実に興味深いところであったが、上記の経験から、自分にとってはセイコー社しかなかった。なお、国産であることの理由は、単純に検討の選択肢を増やすのが面倒くさいということである。

結局、購入したのは「SBGR315」というモデルである。私にとっての「きちんとした」を、手巻き・ノンデイトを除いて満たしている。妥協した理由は、店員から秒針加工技術の話を伺ったことと、金属バンドの装着感が良かったことである。革バンドのモデルもあったが、ちょうどこれから暑くなっていく時期でもあったので、外した。

購入してから

「この腕時計の何が良いのか？」と聞かれたときに、いろいろな答えが出るんだろうと思ったが、実際には答えられないというのが実感である。自分にとって「きちんとした」時計である、というのが答えになるかと思ったが、実際にオーナーになると、この時計に特筆すべき良さは無いと思う。だが、これが左腕に付いていないと、しっくりこないというか、違和感を感じてしまう。そういう意味で、自分にとっては時間に関するパートナーを得たようなものであるからして、パートナーの良し悪しを尋ねるのもナンセンスというものだし、そんなものに答えることは難しいことであるがゆえ、先の質問に答えが出ないのだろうと納得している。

AWS Certified Developer - Associate (DVA-C01)に合格した

Mon, 13 Feb 2023 12:26:36 +0000

AWS Certified Developer - Associate (DVA-C01)に合格しましたので、その記録を書いておきます。

好きなサービス

とりあえず書いておきます。好きなサービスはAmazon S3です。

遍歴

2021年11月 AWS Certified Cloud Practitioner（CLF-C01）取得（799点）
2022年04月 AWS Certified Solutions Architect - Associate（SAA-C02）取得（822点）

そして今回、AWS Certified Developer - Associate (DVA-C01)に合格しました（834点）。これでAWS資格3冠、アソシエイト資格2冠ということになります。

勉強方法

使った資料

ポケットスタディ AWS認定デベロッパーアソシエイト
AWS 認定デベロッパーアソシエイト模擬試験問題集（5回分325問）
Black Belt (X-Ray, KMS, Cognito, CodeStar & CodePipeline, CodeCommit & CodeArtifact, CodeBuild, CodeDeploy. Lambdaは見たかったけど量が多すぎてやめた)
AWS公式ドキュメント
AWS Certified Developer - Associate サンプル問題
AWS Certified Developer - Associate 公式練習問題集

流れ

ポケットスタディを一周する
Udemyの演習テスト1～5までを解いて、解説を読む。最初の2セットは4割くらいの正答率だが、ちゃんと解説を理解すればこのタイミングで残りの3セットは6割くらいはとれるはず。
弱点となったサービスを洗い出す
Black BeltとAWS公式ドキュメントを使って重要なところを整理する
Udemyの325問をもう一回解く（正答率は8割前後を目指す）
サンプル問題と公式練習問題集を一通り解いておく

ポケットスタディ自体は2023年1月13日に購入しましたが、実際に勉強を始めたのは1月22日からなので、概ね3週間くらいで準備したような感じです。

Udemyの問題集の難易度

本番試験では、Udemyの問題集ほど複雑な問題は出てきませんが、それに回答するための要素1つ1つを聞いてくるような印象はありました。BlackBeltなどを使って、要素1つ1つをきちんと整理しておかないと合格は厳しいかなと思います。あと、解説が間違っている、あるいは雑な箇所がいくつかあります。解説を読んでいて「いやいやそうじゃないっしょ」と思いつつAWSの公式ドキュメントを読んで、自分の考え方のほうが正しいということを確認しながら進められるようになれば合格できると思います。そういう意味では、ただ解いて解説を読むことを繰り返すよりも、講師と問題集を通してコミュニケーションをするために知識武装するくらいのつもりでやったほうが面白いと思います。CLF、SAAとも同じですが、問題集を解いて、解説を読んで、だけだと合格は不安かなと。

目安として、Udemyで6割だと合格ラインぎりぎり、7～8割だと余裕をもって合格できるかなという印象です。9割とれるようになるまでやる必要はないと思います。

次のステップ

AWS Certified SysOps Administrator – Associate(SOA-C02)を3月に取得します。

7月末までにSolutions Architect - Professional、9月末までにDevOps Engineer - Professionalを取得し、その後何か専門知識を取りたいというのが当面の目標です。

追伸

aws certifiedのステッカーをもらってきました。Foundamentals、Associateは取得したのでノートパソコンの天板にステッカーを貼っておきました。ProfessionalとSpecialityは、まだ取得していないので自粛しています。

微妙にアピっていきます。では、また明日から頑張りましょう。

SAMを使ってみる

Mon, 23 Jan 2023 10:50:30 +0000

SAMの使い方

大きな流れは以下の通りです。

サーバレスアプリケーションの雛形作成（sam init）
コーディング
ビルド（sam build）
ローカル環境でのテスト（sam local start-api）
デプロイ（sam deploy）

サーバレスアプリケーションの雛形作成

sam init

今回は、以下のような構成を取りました。

テンプレートの種類: AWS Quick Start Templates
使用するテンプレート: Serverless API
ランタイム: Node.js 16.x
X-Rayの使用有無: No X-Ray
アプリケーション名: sam-app

sam init

以下のとおり選択していきます。

You can preselect a particular runtime or package type when using the `sam init` experience.
Call `sam init --help` to learn more.

Which template source would you like to use?
 1 - AWS Quick Start Templates
 2 - Custom Template Location
Choice: 1

Choose an AWS Quick Start application template
 1 - Hello World Example
 2 - Multi-step workflow
 3 - Serverless API
 4 - Scheduled task
 5 - Standalone function
 6 - Data processing
 7 - Infrastructure event management
 8 - Lambda EFS example
 9 - Machine Learning
Template: 3

Which runtime would you like to use?
 1 - dotnet6
 2 - dotnetcore3.1
 3 - nodejs16.x
 4 - nodejs14.x
 5 - nodejs12.x
Runtime: 3

Based on your selections, the only Package type available is Zip.
We will proceed to selecting the Package type as Zip.

Based on your selections, the only dependency manager available is npm.
We will proceed copying the template using npm.

Would you like to enable X-Ray tracing on the function(s) in your application? [y/N]: N

Project name [sam-app]: sam-app

Cloning from https://github.com/aws/aws-sam-cli-app-templates (process may take a moment)

 -----------------------
 Generating application:
 -----------------------
 Name: sam-app
 Runtime: nodejs16.x
 Architectures: x86_64
 Dependency Manager: npm
 Application Template: quick-start-web
 Output Directory: .

 Next steps can be found in the README file at ./sam-app/README.md


 Commands you can use next
 =========================
 [*] Create pipeline: cd sam-app && sam pipeline init --bootstrap
 [*] Validate SAM template: sam validate
 [*] Test Function in the Cloud: sam sync --stack-name {stack-name} --watch


SAM CLI update available (1.70.0); (1.57.0 installed)
To download: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html

コーディング

ディレクトリ構成を確認しておきます。

.
├── buildspec.yml
├── env.json
├── events
│   ├── event-get-all-items.json
│   ├── event-get-by-id.json
│   └── event-post-item.json
├── package.json
├── README.md
├── src
│   └── handlers
│   ├── get-all-items.js
│   ├── get-by-id.js
│   └── put-item.js
├── template.yaml
└── __tests__
 └── unit
 └── handlers
 ├── get-all-items.test.js
 ├── get-by-id.test.js
 └── put-item.test.js

buildspec.yml: CodeBuildの動作を決めるための定義ファイルです。アーティファクトはS3にZIP形式で置かれるようです。
src/handlers/*.js: ソースコードの実体です。CFnのtemplate.yamlから参照されているとおり、このソースコードがLambda関数の実体になります。
__tests__/unit/handlers/*.js: テストコードです。buildspec.ymlで、pre_buildフェーズで実行されるようになっています。
events/*.json: Lambda関数を起動するときに使う起動イベントの定義です。Invocation events that you can use to invoke the function.
env.json: sam local invoke --env-vars env.jsonとすることで、template.yamlに記載されている内容をオーバーライドできる仕組みのためのもののようです（ローカルでの Lambda 関数の呼び出し）。

ビルド

cd sam-app; sam buildで実行できます。

cd sam-app
sam build

以下のように出力されます。

アーティファクト: .aws-sam/build
ビルドに使用したテンプレート: .aws-sam/build/template.yaml

Building codeuri: /home/ec2-user/environment/sam-app runtime: nodejs16.x metadata: {} architecture: x86_64 functions: getAllItemsFunction, getByIdFunction, putItemFunction
Running NodejsNpmBuilder:NpmPack
Running NodejsNpmBuilder:CopyNpmrcAndLockfile
Running NodejsNpmBuilder:CopySource
Running NodejsNpmBuilder:NpmInstall
Running NodejsNpmBuilder:CleanUpNpmrc
Running NodejsNpmBuilder:LockfileCleanUp

Build Succeeded

Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml

Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {stack-name} --watch
[*] Deploy: sam deploy --guided

ローカル環境でのテスト

以下のコマンドにより、ローカル環境でテストできるエンドポイントが提供されます。

sam local start-api

template.yamlで定義された3つのハンドラーに対し、それぞれエンドポイントが提供されていることが分かります。

Mounting getAllItemsFunction at http://127.0.0.1:3000/ [GET]
Mounting getByIdFunction at http://127.0.0.1:3000/{id} [GET]
Mounting putItemFunction at http://127.0.0.1:3000/ [POST]
You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions, changes will be reflected instantly/automatically. You only need to restart SAM CLI if you update your AWS SAM template
2023-01-23 12:12:43 * Running on http://127.0.0.1:3000/ (Press CTRL+C to quit)

ここで、Cloud9で別のターミナルを開き、getAllItemsFunctionを呼び出してみます。

curl http://localhost:3000/

当然ですが、DynamoDBが適切にセットアップされていないのでエラーが返ってきます。また、一番最初にgetAllItemsFunctionを呼び出すときには、Dockerコンテナイメージのダウンロードが行われるため、ややレスポンスが悪いです。

Invoking src/handlers/get-all-items.getAllItemsHandler (nodejs16.x)
Image was not found.
Removing rapid images for repo public.ecr.aws/sam/emulation-nodejs16.x
Building image..............................................................................................................................
Skip pulling image and use local one: public.ecr.aws/sam/emulation-nodejs16.x:rapid-1.57.0-x86_64.

Mounting /home/ec2-user/environment/sam-app/.aws-sam/build/getAllItemsFunction as /var/task:ro,delegated inside runtime container
START RequestId: b38fd596-3599-4c48-bb0b-c4fe0906b982 Version: $LATEST
} version: '1.0': null,',4475962,12:42 +0000',e9808e',b-c4fe0906b982 INFO received: {
2023-01-23T12:15:21.803Z b38fd596-3599-4c48-bb0b-c4fe0906b982 INFO response from: / statusCode: 404 body: Unable to call DynamoDB. Table resource not found.
END RequestId: b38fd596-3599-4c48-bb0b-c4fe0906b982
REPORT RequestId: b38fd596-3599-4c48-bb0b-c4fe0906b982 Init Duration: 1.49 ms Duration: 508.13 ms Billed Duration: 509 ms Memory Size: 128 MB Max Memory Used: 128 MB
No Content-Type given. Defaulting to 'application/json'.
2023-01-23 12:15:21 127.0.0.1 - - [23/Jan/2023 12:15:21] "GET / HTTP/1.1" 404 -

デプロイ

なんとなく動いたことの確認ができたので、デプロイしてみます。

sam deploy --guided

少々ログが長いので、sam-deploy.logに置いておきました。

--guidedをつけてsam deployを起動すると、スタック名やリージョン等が聞かれます。聞かれた内容はsamconfig.tomlに記載され、今後はsam deployを実行するだけで自動的にデプロイされます。

version = 0.1
[default]
[default.deploy]
[default.deploy.parameters]
stack_name = "sam-app"
s3_bucket = "aws-sam-cli-managed-default-samclisourcebucket-1ae5e5y3ql961"
s3_prefix = "sam-app"
region = "ap-northeast-1"
confirm_changeset = true
capabilities = "CAPABILITY_IAM"
disable_rollback = true
image_repositories = []

APIを叩いてみる

POST

実行コマンド

curl -X POST -H "Content-Type: application/json" -d '{"id":"1", "name":"sonohen"}' https://su7cqge7o3.execute-api.ap-northeast-1.amazonaws.com/Prod/
curl -X POST -H "Content-Type: application/json" -d '{"id":"2", "name":"sonohen2"}' https://su7cqge7o3.execute-api.ap-northeast-1.amazonaws.com/Prod/

戻り値

{"id":"1","name":"sonohen"}
{"id":"2","name":"sonohen2"}

GET (All Items)

実行コマンド

curl https://su7cqge7o3.execute-api.ap-northeast-1.amazonaws.com/Prod/

戻り値

[
 { "id": "2", "name": "sonohen2" },
 { "id": "1", "name": "sonohen" }
]

Get (By-Id)

実行コマンド

curl https://su7cqge7o3.execute-api.ap-northeast-1.amazonaws.com/Prod/1 # {"id":"1","name":"sonohen"} should be returned

戻り値

{ "id": "1", "name": "sonohen" }

環境の削除

sam delete

出力例

 Are you sure you want to delete the stack sam-app in the region ap-northeast-1 ? [y/N]: y
 Are you sure you want to delete the folder sam-app in S3 which contains the artifacts? [y/N]: y
 - Deleting S3 object with key sam-app/11e6ad52d95b7ff61f7c5edee5989cc5
 - Could not find and delete the S3 object with the key sam-app/11e6ad52d95b7ff61f7c5edee5989cc5
 - Could not find and delete the S3 object with the key sam-app/11e6ad52d95b7ff61f7c5edee5989cc5
 - Deleting S3 object with key sam-app/a4776539efacb8d6b52ef4f5bcf5a08e.template
 - Deleting Cloudformation stack sam-app

Deleted successfully

感想

正直、SAMのハンズオンをやるかは、ものすごく悩んだ。DVAの教科書を見れば、コマンドの実行例とともにSAMの紹介がなされており、それを読めば十分だろうと思っていたからです。ただ実際にやってみると、SAMでHello Worldレベルのことをやるのに、このブログでメモを取りながらでも1時間くらいだし、最後、環境をきれいに削除してしまうのもCFnならではだなと思いました。実際に時間を使ってやってみると、自分の過去の似たような案件と比較してしまう…いや、してしまうという残念な感じよりも、このプロセスそのものが次の案件に向けては重要なんだろうなと思いました。

Elastic Beanstalkを試してみる

Sun, 22 Jan 2023 03:26:59 +0000

目標

Elastic Beanstalkを使って"Congratulations"してみる。
Blue/Greenデプロイにより、サンプルプログラムの"Congratulations"を"Hello World"に変えてみる。

今回の構成

※相変わらず分かりにくい図で申し訳ないです。

Elastic Beanstalkで"Congratulations"してみる。

アプリケーションの作成

Elastic Beanstalkは初めて使うため（AWS研修では使った経験あり）、AWS Management Consoleから作成しました。

Amazon Correttoとは、Amazonによる無料の長期サポートが提供されている、Java SE標準と互換性があると認定されているOpen JDKディストリビューションのことです。

作成を開始すると、CloudFormationテンプレートによりスタックが作成されていきます。

ハマリポイント1　スタック作成でエラーが発生

エラー内容

次に、CloudFormation > スタック > awseb-e-e7d8kvxdpq-stackを開き、イベントタブを開いたところ、以下のようなエラーが発生し、スタックのステータスはCREATE_FAILEDになっていました。この時、ElasticBeanstalk > 環境 > Beanstalktrial-env-2の環境のヘルスは保留中になっていました。

The following resource(s) failed to create: [AWSEBV2LoadBalancer, AWSEBAutoScalingGroup].

You must use a valid fully-formed launch template. No default subnet for availability zone: ‘ap-northeast-1c’. (Service: AmazonAutoScaling; Status Code: 400; Error Code: ValidationError; Request ID: 7d99081a-1554-487c-b265-38b01661aa2e; Proxy: null)

このエラーの原因は、デフォルトサブネットが存在しないことです。過去にデフォルトVPCを削除した時に、一緒に削除されたのだと思います。そして、現在はデフォルトVPCのみ作成されている状況です。本来、デフォルトVPCは以下のような構成になっているのが正しいようです。

そこで、以下の手順でデフォルトVPC、デフォルトサブネットを構成し直します。

Elastic Beanstalkの環境を削除し、アプリケーションを終了する
デフォルトVPCの記載を参考に、AWS CloudShellから以下のコマンドでデフォルトVPCとデフォルトサブネットを作成する¹

対応1　Elastic Beanstalkの環境を削除し、アプリケーションを終了する

Elastic Beanstalk > 環境から、環境を選択し、右にあるアクションから環境の終了を選択し、環境を終了します。これにより、アプリケーションの公開も停止されます。

対応2　デフォルトVPCを作成する

AWS Cloud Shellから以下のコマンドを実行します。実行しているコマンドの詳細は、AWS CLI Command Referenceを参照してください。

aws ec2 create-default-vpc

出力例は以下です。

An error occurred (DefaultVpcAlreadyExists) when calling the CreateDefaultVpc operation: A Default VPC already exists for this account in this region.

既にデフォルトVPCが存在すると言われます。そこで、デフォルトVPCのVpcIdを調べます。

aws ec2 describe-vpcs --filter Name=is-default,Values=true --query 'Vpcs[].[VpcId]' --output text

出力例は以下です。

vpc-0f48a5ddd72f1781f

既に存在するサブネットの削除

今回は、既にデフォルトVPCが存在していました。その配下にあるサブネットがデフォルトサブネットか判断がつかなかった上、他で使っていなかったことから、デフォルトVPCにあるサブネットを削除しておきます。

for target_subnet in `aws ec2 describe-subnets --filters Name=vpc-id,Values=vpc-0f48a5ddd72f1781f --query 'Subnets[].[SubnetId]' --output text`
do
 aws ec2 delete-subnet --subnet-id $target_subnet
done

以下のコマンドを実行し、出力結果が無いことを以てサブネットが削除されたことを確認します。

aws ec2 describe-subnets \
 --filters Name=vpc-id,Values=vpc-0f48a5ddd72f1781f \
 --query 'Subnets[].[SubnetId]' \
 --output text

デフォルトサブネットの作成

以下のコマンドで、各AZにデフォルトサブネットを作成します。

availabilityzones=(ap-northeast-1a ap-northeast-1c ap-northeast-1d)

for az in ${availabilityzones[@]}
do
 aws ec2 create-default-subnet --availability-zone $az
done

unset availabilityzones

作成されたことを確認します。

aws ec2 describe-subnets \
 --filters Name=vpc-id,Values=vpc-0f48a5ddd72f1781f \
 --filters Name=state,Values=available \
 --query 'Subnets[].[SubnetId,AvailabilityZone,CidrBlock]'

出力例は以下です。

[
 ["subnet-090132d78642c5909", "ap-northeast-1d", "172.31.32.0/20"],
 ["subnet-0a941d6e7b4ae578c", "ap-northeast-1c", "172.31.0.0/20"],
 ["subnet-0374fa703f83f7ae1", "ap-northeast-1a", "172.31.16.0/20"]
]

ドキュメントによると、デフォルトサブネットのCIDRは172.31.0.0/20, 172.31.16.0/20, 172.31.32.0/20の3つであるということなので、きちんと作成されたようです。

インターネットゲートウェイの状況の確認

まず、デフォルトVPCにアタッチされているインターネットゲートウェイのInternetGatewayIdを調べます。

aws ec2 describe-internet-gateways \
 --filter Name=attachment.vpc-id,Values=vpc-0f48a5ddd72f1781f \
 --filter Name=attachment.state,Values=available \
 --query 'InternetGateways[].[InternetGatewayId]' \
 --output text

出力例は以下です。

igw-0adc27eae43d8714d

0.0.0.0/0宛の通信が上記のInternetGatewayを通るように設定されているか、ルートテーブルを確認します。

aws ec2 describe-route-tables \
 --filter Name=vpc-id,Values=vpc-0f48a5ddd72f1781f \
 --filter Name=route.destination-cidr-block,Values=0.0.0.0/0 \
 --filter Name=route.gateway-id,Values=igw-0adc27eae43d8714d \
 --output text

出力例は以下です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


{
 "RouteTables": [
 {
 "Associations": [],
 "PropagatingVgws": [],
 "RouteTableId": "rtb-0ef8c99720a501497",
 "Routes": [
 {
 "DestinationCidrBlock": "172.31.0.0/16",
 "GatewayId": "local",
 "Origin": "CreateRouteTable",
 "State": "active"
 },
 {
 "DestinationCidrBlock": "0.0.0.0/0",
 "GatewayId": "igw-0adc27eae43d8714d",
 "Origin": "CreateRoute",
 "State": "active"
 }
 ],
 "Tags": [
 {
 "Key": "Name",
 "Value": "default-public-rtb"
 }
 ],
 "VpcId": "vpc-0f48a5ddd72f1781f",
 "OwnerId": "436589084651"
 }
 ]
}

0.0.0.0/0宛の通信がigw-0adc27eae43d8714dを通るように設定されていることが確認できました。²

ここまでで、以下の構成が作成されたことが確認できました（以下図は再掲）。

ElasticBeanstalkでアプリケーションを再作成する

再度、ElasticBeanstalkのアプリケーションを作成します。アプリケーションの作成に成功すると、Elastic Beanstalk > 環境にURLが表示されるので、それにアクセスします。すると、以下のように"Congratulations"と表示されるはずです。

ハマりポイント2

私の場合、以前にデフォルトVPCを作成した時に、プライベートサブネット用のルートテーブル、およびパブリックサブネット用のルートテーブルの2つを作っており、デフォルトのルートテーブルは「プライベートサブネット用のルートテーブル」でした。その結果、Beanstalkのアプリケーションを作成した際に、EC2インスタンスは「プライベートサブネット」に配置されており、それが原因でヘルスチェックに失敗する、必要な情報がELB側で取得できない等の問題が発生しました。解決するため、Beanstalkが作ったEC2インスタンスが配置されているサブネットのルートテーブルを「パブリックサブネット用のルートテーブル」に関連付けし直し、環境を再構築しました。

Hello Worldの作成

Cloud9環境の構築

サクッと作っておきます。今回は、ap-northeast-1dに配置しました。

Hello Worldの作成

Elastic Beanstalk resourcesにcorretto.zipがあるので、Cloud9のターミナルを使ってダウンロードし、展開しておきます。

wget https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/samples/corretto.zip
unzip corretto.zip -d sample/

続いて、sample/src/main/resources/index.htmlを開き、以下のように編集します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


<html>
 <head>
 <title>Hello World</title>
 </head>
 <body>
 <h1>Hello World</h1>
 <p>
 This is a end of the Web as there are no links in this page. Hello World.
 </p>
 </body>
</html>

アップロードできるよう、cd sample; zip corretto-2.0.zip -r .で圧縮しておきます。

Blue/Greenデプロイの実行

環境のクローン

現在動作している環境をクローンします。Elastic Beanstalk > 環境を開き、ラジオボタンにチェックを入れ、アクションから環境のクローンを作成を選択します。ひとまずはデフォルト設定のままクローンします。新しい環境の名前は「beanstalktrial-env-1」になりました。現時点で環境は2つあり、それぞれURLは以下の通りになっています。

1つ目、2つ目のURLにアクセスし、「Congratulations」が表示されていることを確認します。

ZIPファイルのアップロードとデプロイ

先ほど作成したcorretto-2.0.zipを、Green環境（Beanstalktrial-env-1）にアップロードし、デプロイします。Elastic Beanstalk > 環境 > beanstalktrial-env-1を開き、アップロードとデプロイを選択します。ZIPファイルをアップロードし、デプロイが完了するのを待ちます。

デプロイが完了した後、先ほどの2つ目のURLにアクセスし、「Hello World」が表示されていることを確認します。1つ目のURLは引き続き「Congratulations」になっていることを確認しておきます。

Blue環境とGreen環境の切り替え

Elastic Beanstalk > 環境を開き、Green環境（Beanstalktrial-env-1）を選択し、アクションから環境URLのスワップを選択します。次の画面で、スワップする環境の選択で、環境名に「Beanstalktrial-env」を選択し、スワップを押下します。最近のイベントを確認すると、Swapping CNAMEs for environments 'Beanstalktrial-env-1' and 'Beanstalktrial-env'.と記載がある通り、スワップはRoute 53のCNAMEレコードの変更によって実現されています。

ここで、Elastic Beanstalk > 環境を開き、2つの環境のURLがスワップされていることを確認します。

これでBlue/Greenデプロイが完了しました。

まとめ

非常に単純な操作によって、Blue/Greenデプロイが出来ることが分かりました（小並感）。

Elastic Beanstalk自体は、AWS研修でもハンズオンを実施したことがありましたが、やはりそこは研修環境、トラブルなんて起こりません。今回は、自分のAWS環境を使って実行したので、デフォルトVPCやデフォルトサブネットが壊れていたこと、デフォルトルートテーブルがプライベート用になっていたことなど、ここに書いていないことも含めてハマりポイントがありました。過去xx年の経験によって、こういうハマりポイントを経て人は強くなっていくということを身を持って理解していますので、今後も用意された環境ではなく、自分の環境で色々と操作を試していきたいと思います。

起動する際、選択しているリージョンに注意してください。今回は、Elastic Beanstalkをap-northeast-1（東京リージョン）で起動したいので、それを指定した後、AWS CloudShellを起動しました。 ↩︎
もう少し読み進めて頂くと分かりますが、この確認だけでは不十分です。このルートテーブルがデフォルトルートテーブルになっていることを確認するか、あるいはサブネットのルートテーブルの付け替えをしないといけません。 ↩︎

Twitterをやめた

Mon, 09 Jan 2023 12:15:31 +0000

もともと、Twitterは情報収集を目的に始めたものだった。その中で、自分が得た情報を発信し、何らかの反応が得られることを知ると、目的が人から反応を得ること、に徐々にすり替わった。つまり、反応を得るための情報収集、情報発信になっていったのだ。インフルエンサーでもなし、見ず知らずの人からリアクションが得られたところで何になるだろう？　そんなことを思うと、急にTwitterがくだらないと思ってしまったのだ。しかし、ふと第三者視点からTwitterに書き込む自分の姿を観察すると、承認欲求というものは厄介なもんだと思う。

辞めるにあたって、ツイートしたものは全て自分の手で削除し、いいねしたものを全て自分の手で外し、フォロワーにも感謝しつつ外した。いいねを外しながら、当時の自分は何を思ってこの人のツイートにいいねをしたのかさっぱり思い出せなかった。「どうでもいいね」だったのかもしれない。

面白いと思ってやっていたときもあるし、今この瞬間にも面白いと思って使っている人がいるんだろうから悪く言うつもりも無いが、思ってしまったことは思ってしまったことだし、過去にも何回か同じような理由で始めてはやめてきた経緯もあることから、とりあえずここに書いておくことにした。

Pixel Watchを買った

Fri, 06 Jan 2023 08:10:00 +0000

買い方

アメリカン・エキスプレス・カード + メンバーシップ・リワード・プラスで購入したので、100円につき3ポイント（3%）の還元があり、実際に1,194ポイントの還元があった。このポイントを1ポイント1円として使うかどうかは自分次第ではあるが。

写真

購入後にやったこと。

バンドの装着順を交換した。普段は左手に装着するが、手首を曲げたときにリュウズが左手の甲に当たるため。
Google KeepのアプリをPixel Watchに入れた。音声でメモが取れるのはやはり良い。

よく分からないこと。

AnkerのSoundCore Libertyを使っているわけだが、これとPixel Watchのペアリングが必要なのか否か。どうもPixel Watchから、ペアリングしているスマートフォンを通して電話が掛けられるのだが、その音声をPixel Watchのスピーカーやマイクから垂れ流すというのはちょっとできない。
Pixel Watch自体に何かファイルを入れたりはできないのか？というよりその辺の思想がよくわからない。Pixel Watchはスマホのインタフェースの1つに当たるのか、それともそれ単独で何かできるようになっているのか。
Chromebook、Pixelスマホ、Pixel Watch、他Google製品との連携エコシステムはまだ良くわからないことが多い。このあたりはAppleがよくできていると思う。

事前に気になっていたことと現在

事前に調べていて気になった「バッテリーの持ち」は、「常時点灯」と「傾けて点灯」をOFFにしておけば、活動量計＋たまの通知確認程度の自分の用途では少なくとも日中は問題なく持つ。時間を確認するのに、いちいち画面タップが必要なのが面倒ではあるが。「傷の付きやすさ」については分からないが精密機器として丁重に扱っていればつきにくいとは思うがまだ良くわからない。

最後に

こんなことを思いながら使っていると、Apple Watchの第2世代を使っていたときのことを思い出す。処理は遅い、バッテリーは持たない、傷は付きやすい。それに比べれば、初代としては完成度は高いのではないか。

GitHub Codespacesを試しつつ、Hugoへ移行する

Wed, 04 Jan 2023 09:07:32 +0000

試す上での縛り

Chromebookで全ての作業（このブログの執筆も含む）を完結させる
ブラウザ（Chrome）だけで全ての作業（このブログの執筆も含む）を完結させる

試す手順

リポジトリの準備

GitHub上で、プライベートなリポジトリ（ここでは「hugo-blog」とする）を作成しておく。あわせて「draft」という名前でブランチを作っておく。以降、全ての作業はこのdraftブランチを軸に行っていく。

Codespacesの起動

「hugo-blog」リポジトリ、「draft」ブランチを選択してCodespacesを起動する。

メニューバーの「Codespaces」を選択して起動する方法もある。[Codespaces] > [New codespace]の順に操作し、起動パラメータを以下の通り設定してもよい。

起動後の画面はWeb版VS Codeなり。

hugoの最低限の設定

初期状態で、hugoはインストールされている（パス：/usr/local/hugo/bin/hugo）。hugoのQuick Startに沿って作業を進める。

/workspaces/hugo-blog (draft) $ hugo new site . –force
/workspaces/hugo-blog (draft) $ git submodule add https://github.com/theNewDynamic/gohugo-theme-ananke themes/ananke
/workspaces/hugo-blog (draft) $ echo "theme = 'ananke'" >> config.toml
/workspaces/hugo-blog (draft) $ hugo server

そうすると、Codespaceの中で動作しているhugoのポートと、外部からアクセスできるアドレス（ローカルアドレス）のバインドが行われ、「ポート」タブに表示される。ローカルアドレスにアクセスすれば、Codespaceの中で動作しているhugoのサーバにアクセスできる。

アクセスすると、以下の通りhugoで作成したサイトが表示される。

一旦、ここまでの変更をコミットしておく。

hexoからhugoへの移行

ここから先は、hexoからhugoへの移行の記録である。

submoduleの削除

themes/anankeは使わないので削除しておく。

/workspaces/hugo-blog (draft) $ git submodule deinit -f themes/ananke
/workspaces/hugo-blog (draft) $ rm -rf themes/ananke

テーマの選定

今回はsimplenessというものにした。シンプルでヨシ。

/workspaces/hugo-blog (draft) $ git submodule add https://github.com/RainerChiang/simpleness.git themes/simpleness

config.tomlの変更

config.tomlを変更する。とりあえずはデフォルトで記載されている以下のパラメータを変更しておく。動けばヨシ。

baseURL = 'https://sonohen.github.io/'
languageCode = 'ja-jp'
title = 'とあるエンジニアの備忘録'
theme = 'simpleness'

.gitignoreの作成

以下を追加しておく。

/public/
/resources/_gen/
.hugo_build.lock

動作確認

ここまでで動作するかを確認しておく。

/workspaces/hugo-blog (draft) $ hugo server -D

theme/simplenessは、各種リソースをlocalhost:1313から取得しようとしてしまうのでこれだと正しく動作しない。その場合は、以下のコマンドで対処する。

/workspaces/hugo-blog (draft) $ hugo server -D --baseUrl="https://sonohen-scaling-space-pancake-j4wxjgjq9r2qxxj-1313.preview.app.github.dev/" --appendPort=false

もう少し良いやり方があると思うが、とりあえずはこれで動いたのでヨシ。

ここで一旦、コミットしておく。

記事・静的ファイルの移行

hugoの場合、/contentに記事本体（*.md）、/staticに静的ファイル（*.jpg等）を入れておけば良いらしい。また、hexoで書いていた記事は「hexo」という名前のリポジトリに保存してあるので、スマートではないがとりあえず以下の方法で移行する。

# 鍵の作成
/workspaces/hugo-blog (draft) $ ssh-keygen -t rsa
/workspaces/hugo-blog (draft) $ cat ~/.ssh/id_rsa.pub # 公開鍵をGitHubに登録する

# 接続テスト
/workspaces/hugo-blog (draft) $ ssh -T git@github.com
Hi sonohen! You\'ve successfully authenticated, but GitHub does not provide shell access.

# 移行作業
/workspaces/hugo-blog (draft) $ mkdir content
/workspaces/hugo-blog (draft) $ cd ../
/workspaces/ $ git clone git@github.com:sonohen/hexo.git
/workspaces/hexo/source (master) $ cp -Rp ./_posts/ /workspaces/hugo-blog/content/
/workspaces/hexo/source (master) $ cp -Rp ./images/ /workspaces/hugo-blog/static/
/workspaces/hexo/source (master) $ cd /workspaces/hugo-blog

# 動作確認
/workspaces/hugo-blog (draft) $ hugo server -D --baseUrl="https://sonohen-scaling-space-pancake-j4wxjgjq9r2qxxj-1313.preview.app.github.dev/" --appendPort=false

ここで以下のように表示されればうまく移行できたと思われる。

GitHub Actionsを利用した自動デプロイ

/content/_posts/にMarkdownファイルを作成し、コミットしたらsonohen.github.ioに表示されるようにしたい。。

そのためにはリポジトリを開き、[Settings] > [Build and deployment] > [Source]からGitHub Actionsを選択し、[Hugo] > [Configure]を選択し、次の画面でCommitすればよい。次のコミット分からGitHub Actionsで自動デプロイされる。

Amazon WorkSpacesの検証をやってみた

Tue, 03 Jan 2023 09:37:30 +0000

Amazon WorkSpacesとは

VDI（Virtual Desktop Infrastructure：仮想デスクトップ基盤）の1つで、シンクライアントとも言われます。皆さんがお勤めの企業でも導入されているかもしれません。Windows等のOSがAWSのデータセンター上で動いており、そこにアクセスして作業します。

個人の場合（例えば私の場合）、以下のユースケースがあるかなと思います。

日常的な作業の大半はChromebookで出来るが、一部の作業でWindowsが必要、だけどWindows端末は持ちたくない、という場合にスポットで利用
特定の国からしかアクセスできないサイトにアクセスする場合に、その国に設置されているリージョンにAmazon WorkSpacesを設定し、アクセス（良く分からないVPNを経由してアクセスするよりもAmazon WorkSpacesのほうがセキュアな可能性があります）

背景

Amazon WorkSpacesを試してみようと思ったときに、以下の前提条件で最も費用が安くなるのが米国東部（バージニア北部：us-east-1）です。時間料金を選択すると、1ヶ月あたりの固定費用が9.75 USD/月（約1,227円/月）、利用時間ごとの変動費用が0.30 USD/時間（約40円/時間）です。例えば、月に40時間だけ使うという場合にAmazon WorkSpacesにかかる費用は、9.75 USD + 0.30 USD * 40h = 21.75 USD (約2,845円)です。

前提条件

リージョンは米国東部（us-east）
Windowsバンドルオプション
スタンダード（2 vCPU、4GBメモリ）
ルートボリューム80GB、ユーザーボリューム50GB

ただし、この場合にネックになるのがパフォーマンスです。Amazon WorkSpacesの管理ドキュメントによると以下のような記載があります。

PCoIP のパフォーマンスを最大限に高めるには、クライアントネットワークからWorkSpaces があるリージョンまでのラウンドトリップ時間 (RTT) が 100ms 未満でなければなりません。RTT が 100 ミリ秒から 200 ミリ秒の間にある場合、ユーザーはWorkSpace にアクセスできますが、パフォーマンスに影響します。RTT が 200 ミリ秒～375 ミリ秒の間にある場合、パフォーマンスは低下します。RTT が 375 ミリ秒を超えると、WorkSpacesクライアント接続は終了します。

WorkSpaces Streaming Protocol (WSP) の最高のパフォーマンスのためには、クライアントのネットワークから WorkSpaces があるリージョンまでの RTT が 250 ミリ秒未満でなければなりません。RTT が 250 ミリ秒から 400 ミリ秒の間にある場合、ユーザーはWorkSpace にアクセスできますが、パフォーマンスは低下します。

― AWS, Amazon WorkSpaces クライアントネットワークの要件

Amazon WorkSpacesのConnection Health Checkを見ると、日本国内からアクセスしたときの米国東部までのラウンドトリップ時間（以下RTT）は380msと表示されており、上記の記載に照らし合わせるとWorkSpaceにアクセスできないことになります。しかし、実際にはアクセスし、操作できます。ここで確認できるRTTと、実際にWorkSpacesのクライアント（Android版）から確認できるRTTは大きく乖離している場合があるためで、クライアントから確認できるRTTは186msでした。よって、RTTを確認する際には、実機にクライアントを入れて確認するのが一番良いと思います。

目的

以下の操作を行い、体感性能がどの程度であるのかを把握します。

WorkSpacesにログインする
ソフトウェア（Google Chrome）をインストールする
Google Chromeで速度測定（speed.cloudflare.com）を行う
タスクマネージャや設定画面を開く

環境

見て分かる通り、private-subnet-(1a|1b)は不要です。なぜ作ったかというと、もともとSimple ADとAmazon WorkSpacesはprivate-subnet-(1a|1b)に配置する計画でしたが、その場合、public-subnetにNATゲートウェイを設置する必要があり、そのコストが勿体ないと気がついたのが、public-subnetの作成後だったからです。

結果

作業をしている時に撮影した動画をYouTubeにアップロードしました。

ポイントは以下のとおりです。

RTTは178ms（2023年1月2日20:00〜20:02に撮影）であったが、軽い作業であればレスポンスが気になることは少ないと思われる
Google Chromeをインストールし、Chromeで速度測定を行う程度であれば体感上、遅いと感じることはない。ただ、CloudFlareを開いたときの引っかかりはややあるかという程度（Intel Celeron N4020を搭載したChromebook HP 14aでCloudFlareを開いたときよりはマシという程度）
OSはWindows Server 2016 Datacenter (1607)
WorkSpaceとインターネット（CloudFlare）の間のダウンロード速度は1.10Gbps、アップロード速度は926Mbps。Ping値は低いがJitter値がやや高い
何も作業していない状態で、メモリは51%が使用されており、CPU使用率は5%前後位を推移。割り当てられているCPUは「Intel Xeon Platinum 8259CL CPU 2.5Ghz (2vCPU)」、メモリは4GB

今後について

メインマシンをChromebookに置き換えたので、年賀状印刷（特に宛名印刷）だけのためにWindows端末が必要な状況です。WorkSpaceに筆王をインストールし、自宅にVPNで接続後、自宅に据え付けているネットワークプリンタ（DCP-J4140N）を使って宛名印刷が出来るようにしてみたいと思います。今どき、宛名印刷はネットで注文できるのでこのような手間をかける意味は無いですが。

ITエンジニアに求められる姿勢、または能力に関する私見

Sun, 01 Jan 2023 09:51:59 +0000

はじめに

「ITエンジニア」にも色々いますが、特に大手企業から受託してシステム・インテグレーションを行っている人々のことを想定しています。あまり関係ないかもしれません。

私が思うITエンジニアに求められる姿勢、または能力には3つのものがあると思います。

自社の課題と、顧客企業の課題を捉え、または捉えようとし、それを解決し、または解決しようとする姿勢、能力
常に身の回りに疑問を持ち続け、それを解決し、または解決しようとする姿勢、能力
言語を正しく運用する能力

ここでは、個々に対して私見を整理したいと思います。

自社の課題と、顧客企業の課題を捉え、または捉えようとし、それを解決し、または解決しようとする姿勢、能力

顧客がIT投資の意思決定を行う背景には、大なり小なり課題があります。何の課題もないところに投資を行う必要はないということです。そして顧客は、課題を解決してくれる（と期待する）ベンダーにシステム開発を委託します。委託された側は、顧客の課題を、自らが持つアセットを使って解決しようとします¹。これらの流れが途中で断ち切られると、IT投資は必ず失敗に終わります。

ここで、以下のような疑問が出てきます。

顧客はベンダーに課題を正確に伝えてくるでしょうか。
ベンダーは、「他社」のビジネスと課題を正確に理解できるでしょうか。
自社が持つアセットと自社の課題（不十分なところ）を正確に理解しているでしょうか。
顧客と自社のそれぞれが持つ課題は、現場とマネジメントで一致しているでしょうか。

まず、顧客がベンダーに課題を正確に伝えてくることは稀だと思います。それは、顧客自身が正確に認識していないこともあれば、ベンダーからすれば他社のビジネスにおける課題なわけで、言葉の使い方、ニュアンスや温度感などを取り違えるなんていうことはザラでもあるからです。ゆえに、顧客とベンダーは、様々な技法を用いて、ビジネスと課題を共通認識のもとに捉えていくことが求められます。技法には「ドメイン駆動設計」のようなものがあれば、「デザイン思考」といったものもあるかもしれません。いずれにしても、双方向の取り組みが必要になるということです。

そして、ビジネスと課題を共通認識のものにできたら、ベンダーは課題を解決、または整理しなければなりません。ここでは解決すると決めた課題について書きます。業界には課題を解決するための技術が多くあり、その技術は更に「基本」と「応用」に分解できます。応用部分に対して、各社が持ち合わせているアセットやその深度は多種多様で、強みもあれば、弱みもあります。そして多くの場合、顧客の課題を解決するのは「応用の技術」です。したがって、自社の何が強みで、何が弱みなのか。それに対してどのように対応しようとしているのか。これが自社の課題であり、顧客と対峙するときには、常に正しく認識しておくことが重要です²。これは何も強みを活かして対応しましょうということではありません。強みを活かすことも大事ですが、顧客からの求めによっては、弱みを課題として認識して対処する必要があるということです。

常に身の回りに疑問を持ち続け、いくつかを課題と捉え、それを解決し、または解決しようとする姿勢、能力

1つ目の話は、いわばトップダウンの考え方です。ビジネスを理解し、課題を抽出し、自社の課題を踏まえて顧客課題の解決を目指す、という3段階の流れです。ここでは、ボトムアップの考え方を書きたいと思います。

先に「基本」と「応用」という言葉を使いました。「基本」とは、長きにわたって変わらないもので、常に立ち戻ることができる地点のことを意図して書いています。これに対して「応用」とは、基本を土台と捉え、その土台の上に成り立つ概念を意図して書いています。あるいは、応用が土台となり、その土台の上に成り立つ概念でもあります。例えば、何かをしようとした時に、ある方法よりも正確に行える方法、効率が良い方法、安全性が高い方法などを意図しています。

まず、何においても「基本と応用の技術」を習得・研鑽することが肝要で、どちらかといえば基本に注力することが大事です。この理由は2つあります。まず、基本に注力すべき理由ですが、基本は応用の土台であり、不安定な土台のうえに物は載らない、あるいは載ったとしても不安定であり、もっと言えば載った状態の再現性が低いからです。次に、技術の習得と研鑽が肝要であるとする理由ですが、人は知らないことに対して疑問を持つことができないからです。人が疑問を持つのは、自分が知っている道理に沿って物事が進まないときです。人は何かを知り、そこから外れたものに対して疑問を持ち、その疑問の一部は、自分に不足している基本や応用の技術で塗り替えられ、そうでないものはやがて課題に置き換わっていきます。課題とは何かを達成するための障壁です。だから、「基本と応用の技術」の習得・研鑽は重要なのです。

私の仕事はチームで仕事をするので、ここで「チーム」という言葉を考えたいと思います。そもそもチームとは個人の集団であって、チームを組む理由（意味）は（1）個人ではなし得ないことをやり遂げること、または、（2）そのやり遂げる結果が、個々の成果の総和を超えること、にあると考えます。特に（2）を目指すなら、そこに集まる個人によってチームとしての「基本と応用の技術」の幅が広げられ、かつ深くなっている状態でなければなりません³。さらに、その多様性を発信し、また個々人が受け入れることができる土壌も必要です。”Diversity and Inclusion”（多様性の受け入れ）の意味の1つはこれにあるのではないでしょうか。

その中で、個人が持つ「基本と応用の技術」の範囲で、常に身の回りに疑問を持ち続けることが大切です。具体的には、「自分と周りが正しい⁴ことをしているか」を問い続けることです。断面はいくつかあるでしょう。ビジネス理解、課題抽出、設計、実装、テスト。アーキテクチャ。マネジメント。もっと広くは組織。それぞれに対し、「基本と応用の技術」を当てはめたときに、個人が疑問を生み出すことができ、その一部を個人またはチームの課題と捉えられるかどうかが、チームとしての成果を生み出せるか否かに関わり、ひいては顧客の課題を解決できるかどうかにも関わるのだと思います。

言語を正しく運用する能力

最後は、「言語」の話です。

私の仕事の成果は、すべて「言語」で成り立っています。言葉には2つあり、1つは日本語や英語といった人間同士が使う言語（これを便宜上、会話言語とします）、もう1つはサーバやネットワーク等のインフラ、およびそれらの上で動作する各種ソフトウェアを開発または統合し、動作させるために必要な言語（あるいはパラメータ類）です。

それを生産するプロセスは大きく3つに分けられると思います。1つ目は顧客のビジネスや課題を、会話言語を用いて言語化して共通認識の下に置くこと、2つ目は、その課題を解決するための方法を「基本と応用の技術」を用いて考えること、３つ目は、考えた解決策をコンピュータ等が理解できる形に変換することです。これらのすべてで言語が使われ、そして最終的に変換するということは、変換元となるものの解釈を誤ってはならないですし、変換も正確に行われなければなりません。それぞれの対象に適した言語を適切に運用しなければならないのです。

よりよい（より伝わり易い）言い回しがないか、よりよい実装の仕方はないかを常に自分に問いながら、言語を正しく運用していきたいものです。

まとめ

勘違いしないで頂きたいのは、あくまで上記は私見であり、また、自分が出来ていると思っているものでもないということです。また、人によって置かれた状況が異なるため、ITエンジニアに求められるものも人それぞれ、またはその時々によって変わるものと思います。

ただ、現時点でITエンジニアに求められるものは、ここに書いた3つのことに帰結するのではと私は思っていますし、少なくとも2023年においても私とチームの課題でもあると思っていますので、ここに書いたことを念頭に置きながら仕事をしていきたいと考えています。

では、よいお年を。

実際には、QCD等に代表される「制約」の範囲において、です。 ↩︎
一方で顧客は、そのベンダーの強みと弱みを理解し、課題を解決する道筋を立てられるか、その道筋に適合するかを自分たち、またはコンサルティングファームのコンサルタントと一緒に考え、自分たちの解を持っておくことが重要です。 ↩︎
マネジメントの要素もありますが、ここでは話を単純にするために書かないことにします。 ↩︎
「正しい」とは、あらゆるレベルで共有された目標・目的に向かって、まっすぐの方向へ推し進めようとする力のことです。 ↩︎

ブログ環境をGitHubからAWSに移行しました

Tue, 06 Dec 2022 11:24:12 +0000

今までの構成

今までは、静的CMSであるHexoを使ってローカル環境で各ページを生成し、生成されたページをGitHub Pagesで公開する、という構成を取っていました。

この構成を取っていた理由は以下の2つです。

ブログ記事をMarkdown形式で書くことができ、HTMLを作るために必要なテンプレートや設定ファイルをgitで管理できるため
GitHub Pagesは、リポジトリにgit pushさえすればページが公開され、かつ無料で気軽に使うことができるため

しかし思うところがあり、今回、この構成をAWSに移行することにしました。

新たに構築した構成

新たに構築した構成のイメージは以下の通りです。

ポイントは以下のとおりです。

Chromebookで執筆した記事をCodeCommitにgit pushすると、CloudWatch EventsがCodePipelineを起動する
CodeBuildが、/buildspec.ymlに記載された内容に基づき、hexo generateを実行する。そして、生成されたHTML（./public/配下）をS3バケットとaws s3 syncで同期する

これにより、（1）source/_pages/にMarkdown形式で記事を書いた記事を保存する、（2）git commitとgit pushを実行する、だけで、自動的にブログ記事が公開されるわけです。

ハマったポイント

`git clone ssh://git-codecommit.ap-northeast1-amazonaws.com/v1/repos/...`で、`Permission denied (publickey).`が発生し、cloneに失敗する

確認したポイントは以下です。

~/.ssh/id_rsa（秘密鍵）のパーミッションが400になっていること
Management ConsoleのIAM > ユーザー > 認証情報 > AWS CodeCommit の SSH キーに、~/.ssh/id_rsa.pubの内容が正しく登録されていること

これでもエラーが解消しなかったため、Troubleshooting SSH connections to AWS CodeCommitを参考に、git clone ssh://[my-key-id]@git-codecommit.ap-northeast1-amazonaws.com/v1/repos/...を実行したところ、git cloneできるようになりました。my-key-idは、IAMから確認できます。

`buildspec.yml`に記載した`aws s3 sync [src] [dest]`の実行が、`ListObjectsV2`のAccess Deniedエラーで失敗する

Amazon S3 バケットで sync コマンドを実行すると、ListObjectsV2 で Access Denied (アクセス拒否) エラーが表示されるのはなぜですか?によると、ListObjectsV2の実行を許可するためには、IAMでs3:ListBucketsの実行を許可する必要があります。

と、ここまでは良いのですが、何を血迷ったのか、私は以下のように記載し、CodePipelineのサービスロールにアタッチして3時間ほど悩んでいました。

{
 "Effect": "Allow",
 "Action":
 ["s3:ListBuckets", "s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
 "Resource": ["arn:aws:s3:::.../*"],
}

これをアタッチしてから何回もCodePipelineを実行しましたが、毎回毎回ListObjectsV2起因のエラーでパイプラインが止まりました。深夜になっていたこともあり、一旦そこで作業を中断しましたが、翌日、CodePipelineではなく、CodeBuildのサービスロールにアタッチしなければ意味が無いことに気が付きました。（aws s3 syncを呼び出すのはCodePipelineではなくCodeBuildのため）

なぜAWSに移行したのか

昨年、Chromebook hp 14aを購入したのをきっかけに、日常作業のほぼ全てをクラウド環境に移行しました。Windows環境が必要なScanSnapを使った書類のスキャンと、開発作業のためにWindows端末を残しています。

ただ、よくよく考えて見ると、Windows端末での作業もChromebookに移行できそうです。

ScanSnapをWiFi対応のものに買い換えることで、クラウドストレージに直接スキャンデータを保存できるようになりそう
Windowsで実施している開発も、AWSのサービスをうまく組み合わせればWindows環境なしでもいけそう。Cloud9 + なにか、で出来そう。

特に最近、開発に使っているPCのスペックが時代遅れになりつつあり、必要な時に必要なリソースが取れるクラウド環境での開発に興味が出始めています。開発環境をAWSに移行する際には、Codeシリーズの使い方を少しは知っておく必要があるので、研究を兼ねてAWSに移行しました。

今後の構想

以下の5点を年内目処くらいでやっておきたいなと思っています。

Slackからコマンドを投げると、自動的にPipelineが動作するようにする。
CloudFrontを使った配信
S3の非公開化
独自ドメインを使ったアクセス
開発環境の移行。色々やり方はありそう。EC2/ CodeCatalyst/ Cloud9/ WorkSpacesなど。WorkSpacesを使うなら、Wyseの端末を買ってシンクライアント化するのも面白そうではある

ちなみに、

この記事は、富士通のChromebook(14F)で、下書きはDynalistを使って、最終的な整形とgit pushはCloud9を使って書いています。また、構成イメージはdiagrams.netで書きました。

2023/01/09追記

結局、GitHub Pagesに戻しました。

AWS Certified Cloud Practitioner合格記

Thu, 16 Dec 2021 00:24:12 +0000

AWS認定資格の登竜門である「AWS Cloud Practitioner」を受験し、合格したので記録として残します。

バックグラウンド

SIerで、DCの物理配線〜アプリ開発、PMまで幅広く。オンプレも仮想基盤（プライベートクラウド）は利用した経験あり
その後、コンサルファームに移籍
プライベートでは広く浅く勉強するも、パブリッククラウドに対する疑心暗鬼は絶えず

とは言っても、今や猫も杓子もパブリッククラウド（また？）、内製！ローコード！の再燃（何回目や……）もあり、いよいよ勉強しなければと思いつつ、仕事でクラウドを使うこともなかったので、体系的に勉強するために勉強・受験しました。

勉強方法

私は以下で勉強をしました。特にAWS Cloud Practitioner Essentialsは、AWSが何たるかを手っ取り早く掴むのに非常に分かりやすいリソースです。

AWS Skill Builder - AWS Cloud Practitioner Essentials (Japanese)(日本語実写版)
AWS認定資格試験テキスト AWS認定クラウドプラクティショナー
【2022年版】この問題だけで合格可能！AWS 認定クラウドプラクティショナー模擬試験問題集（7回分455問）

合格率は不明ですが（※公表されていない）、ネットの情報を見ていると簡単な資格と錯覚するケースがあるようです。ですが、勉強しないと普通に落ちます。ただし、勉強しても落ちます。何が問われるのかは、模擬試験問題などを見るとわかります。

点数

799点 / 1,000点（※ビミョー）

今後

以下を取得して、次の仕事を探したい。

AWS Certified Solutions Architect - Associate
AWS Certified DevOps Engineer - Associate
AWS Certified SysOps Administrator - Associate

dnfでRepository is listed more than once in the configurationが表示された場合の対応

Sat, 08 May 2021 20:45:53 +0000

結論としては、/etc/yum.repos.d/の配下に別名で、中身が（ほぼ同じ）ファイルが2つ存在したための警告メッセージであったため、重複しているものを無効にすることでメッセージの出力を抑制した。

$ ls -alh /etc/yum.repos.d/
合計 60K
drwxr-xr-x. 1 root root 664 5月 8 19:48 .
drwxr-xr-x. 1 root root 5.3K 5月 8 19:51 ..
-rw-r--r--. 1 root root 190 4月 28 21:29 1password-beta.repo
-rw-r--r--. 1 root root 210 5月 7 01:01 1password.repo
-rw-r--r--. 1 root root 311 1月 26 14:48 _copr_phracek-PyCharm.repo
-rw-r--r--. 1 root root 728 4月 29 02:31 fedora-cisco-openh264.repo
-rw-r--r--. 1 root root 1.3K 4月 29 02:31 fedora-modular.repo
-rw-r--r--. 1 root root 1.4K 4月 29 02:31 fedora-updates-modular.repo
-rw-r--r--. 1 root root 1.4K 4月 29 02:31 fedora-updates-testing-modular.repo
-rw-r--r--. 1 root root 1.4K 4月 29 02:31 fedora-updates-testing.repo
-rw-r--r--. 1 root root 1.3K 4月 29 02:31 fedora-updates.repo
-rw-r--r--. 1 root root 1.3K 4月 29 02:31 fedora.repo
-rw-r--r--. 1 root root 173 5月 8 19:48 google-chrome.repo
-rw-r--r--. 1 root root 1.5K 1月 26 14:48 rpmfusion-nonfree-nvidia-driver.repo
-rw-r--r--. 1 root root 1.4K 1月 26 14:48 rpmfusion-nonfree-steam.repo
-rw-r--r--. 1 root root 148 5月 1 21:00 skype-stable.repo
-rw-r--r--. 1 root root 154 5月 1 21:02 teams.

なぜか1passwordのrepoが2つ存在している。ので、これのうち一つをどこかに移してしまえば良さそう。というわけで、どちらを残すのか中身を確認してみる。

$ diff 1password.repo 1password-beta.repo
2,3c2,3
< name="1Password Beta Channel"
< baseurl=https://downloads.1password.com/linux/rpm/beta/$basearch
---
> name=1Password
> baseurl=https://downloads.1password.com/linux/rpm/beta/x86_64
7c7
< gpgkey="https://downloads.1password.com/linux/keys/1password.asc"
---
> gpgkey=https://downloads.1password.com/linux/keys/1password.asc

細かい差分はさておき、注目すべき差分は 1password.repo の $basearch である。ここで、 $basearch には x86_64 が入る（see 6.3.3 Yum 変数の使用) ということなので、つまり2つのファイルに差分は見受けられない。

ゆえに、1password for Linux はbeta版であるので、/etc/yum.repos.d/1password-beta.repoを残す方針とする。

$ sudo mv 1password.repo 1password.repo.old
$ sudo dnf update
メタデータの期限切れの最終確認: 1:56:41 時間前の 2021年05月08日 18時22分17秒 に実施しました。
依存関係が解決しました。
行うべきことはありません。
完了しました!

ついでに、/etc/yum.repos.d/google-chrome.repoも削除しておいた（Firefoxに移行したため）。

Rcloneの使い方

Wed, 05 May 2021 21:56:43 +0000

Rcloneとは

Rclone is a command line program to manage files on cloud storage. It is a feature rich alternative to cloud vendors’ web storage interfaces. Over 40 cloud storage products support rclone including S3 object stores, business & consumer file storage services, as well as standard transfer protocols.
― Rclone, Rclone

つまるところ、Rcloneはクラウドストレージを操作するためのコマンドライン・インタフェースであり、40を超えるクラウドサービスに加え、標準的な転送プロトコル（SFTP等）もサポートしているというものです。

使い方

使用する前に、設定を行う必要があります。ここでは、onedriveを例に記載します。

**に囲まれている箇所が入力する箇所です。

$ rclone config
2021/05/05 21:34:53 NOTICE: Config file "/home/sonohen/.config/rclone/rclone.conf" not found - using defaults
No remotes found - make a new one
n) New remote
s) Set configuration password
q) Quit config
n/s/q> n
name> **onedrive**
Type of storage to configure.
Enter a string value. Press Enter for the default ("").
Choose a number from below, or type in your own value
 1 / 1Fichier
 \ "fichier"
 2 / Alias for an existing remote
 \ "alias"
 3 / Amazon Drive
 \ "amazon cloud drive"
 4 / Amazon S3 Compliant Storage Providers including AWS, Alibaba, Ceph, Digital Ocean, Dreamhost, IBM COS, Minio, and Tencent COS
 \ "s3"
 5 / Backblaze B2
 \ "b2"
 6 / Box
 \ "box"
 7 / Cache a remote
 \ "cache"
 8 / Citrix Sharefile
 \ "sharefile"
 9 / Compress a remote
 \ "compress"
10 / Dropbox
 \ "dropbox"
11 / Encrypt/Decrypt a remote
 \ "crypt"
12 / Enterprise File Fabric
 \ "filefabric"
13 / FTP Connection
 \ "ftp"
14 / Google Cloud Storage (this is not Google Drive)
 \ "google cloud storage"
15 / Google Drive
 \ "drive"
16 / Google Photos
 \ "google photos"
17 / Hadoop distributed file system
 \ "hdfs"
18 / Hubic
 \ "hubic"
19 / In memory object storage system.
 \ "memory"
20 / Jottacloud
 \ "jottacloud"
21 / Koofr
 \ "koofr"
22 / Local Disk
 \ "local"
23 / Mail.ru Cloud
 \ "mailru"
24 / Mega
 \ "mega"
25 / Microsoft Azure Blob Storage
 \ "azureblob"
26 / Microsoft OneDrive
 \ "onedrive"
27 / OpenDrive
 \ "opendrive"
28 / OpenStack Swift (Rackspace Cloud Files, Memset Memstore, OVH)
 \ "swift"
29 / Pcloud
 \ "pcloud"
30 / Put.io
 \ "putio"
31 / QingCloud Object Storage
 \ "qingstor"
32 / SSH/SFTP Connection
 \ "sftp"
33 / Sugarsync
 \ "sugarsync"
34 / Tardigrade Decentralized Cloud Storage
 \ "tardigrade"
35 / Transparently chunk/split large files
 \ "chunker"
36 / Union merges the contents of several upstream fs
 \ "union"
37 / Webdav
 \ "webdav"
38 / Yandex Disk
 \ "yandex"
39 / Zoho
 \ "zoho"
40 / http Connection
 \ "http"
41 / premiumize.me
 \ "premiumizeme"
42 / seafile
 \ "seafile"
Storage> **26**

*See help for onedrive backend at: https://rclone.org/onedrive/*

OAuth Client Id
Leave blank normally.
Enter a string value. Press Enter for the default ("").
client_id>**[Blank]**
OAuth Client Secret
Leave blank normally.
Enter a string value. Press Enter for the default ("").
client_secret>**[Blank]**
Choose national cloud region for OneDrive.
Enter a string value. Press Enter for the default ("global").
Choose a number from below, or type in your own value
 1 / Microsoft Cloud Global
 \ "global"
 2 / Microsoft Cloud for US Government
 \ "us"
 3 / Microsoft Cloud Germany
 \ "de"
 4 / Azure and Office 365 operated by 21Vianet in China
 \ "cn"
region> **1**
Edit advanced config? (y/n)
y) Yes
n) No (default)
y/n> **n**
Remote config
Use auto config?
 * Say Y if not sure
 * Say N if you are working on a remote or headless machine
y) Yes (default)
n) No
y/n> **y**
If your browser doesn't open automatically go to the following link: http://127.0.0.1:53682/auth?state=xxx
Log in and authorize rclone for access
Waiting for code...
**ここでブラウザが開くので、Microsoftアカウントでログインし、画面の指示に従う。**
Got code
Choose a number from below, or type in an existing value
 1 / OneDrive Personal or Business
 \ "onedrive"
 2 / Root Sharepoint site
 \ "sharepoint"
 3 / Sharepoint site name or URL (e.g. mysite or https://contoso.sharepoint.com/sites/mysite)
 \ "url"
 4 / Search for a Sharepoint site
 \ "search"
 5 / Type in driveID (advanced)
 \ "driveid"
 6 / Type in SiteID (advanced)
 \ "siteid"
 7 / Sharepoint server-relative path (advanced, e.g. /teams/hr)
 \ "path"
Your choice> **1**
Found 1 drives, please select the one you want to use:
0: (personal) id=xxx
Chose drive to use:> **0**
Found drive 'root' of type 'personal', URL: https://onedrive.live.com/?cid=xxx
Is that okay?
y) Yes (default)
n) No
y/n> **y**
--------------------
[onedrive]
type = onedrive
region = global
token = {"access_token":"","token_type":"Bearer","refresh_token":"","expiry":"2021-05-05T22:36:16.565429024+09:00"}
drive_id = xxx
drive_type = personal
--------------------
y) Yes this is OK (default)
e) Edit this remote
d) Delete this remote
y/e/d> **y**
Current remotes:

Name Type
==== ====
onedrive onedrive

e) Edit existing remote
n) New remote
d) Delete remote
r) Rename remote
c) Copy remote
s) Set configuration password
q) Quit config
e/n/d/r/c/s/q> **q**

使い方

リモート側のファイルを確認する

$ rclone ls onedrive:

リモートからファイルをダウンロードする

$ rclone copy -P onedrive: /path/to/download

他のコマンドは、詳細を参照。

2021年のGWを振り返る

Wed, 05 May 2021 20:27:56 +0000

2021年のGWの目標

以下の目標を立てていました。

自宅のレッツノートのFedora 33からFedora 34へのアップグレード¹
レッツノート²のスクロールをまともに動かすようにする
OneDriveからの脱却のため、NAS（LANDISK）にファイルを移管する
Emacsでeasy-hugo, wanderlust, org-agenda, org-capture, org-roamの設定
GnuCashで使っているMySQLのバックアップ自動化
「TCP/IPの絵本」の読了
「ネットワークはなぜつながるのか」の読了
「マスタリングTCP/IP」の読了

実績

アップデート完了。不具合として認識しているのは、(1)Virt Managerを使った場合のUSB Redirectionの動作不良（詳細）、(2) Pipewireがレッツノート上で機能しない（音が出ない）、の2点。
systemdを使用し、サスペンドからレジュームした際にi2c_hidをmodproveするようにした。これが実に快適。
Personal Valutのほかは、LANDISKに移行完了。同時に、自宅のネットワークに接続している場合、自動でmountするように自動化した。
いずれも設定完了。
今週末対応予定。
読了。
途中まで読んだ（10%程度）。
未着手。

今後実施したいこと

1passwordに月会費を支払っているので、bitwarden等に移行したい。
低レベルプログラミングへの着手。

毎年支払っているOffice 365の年間サブスクリプション（年額約1万3千円程度）を節約するため、徐々にMicrosoftから離れつつあります。 ↩︎
CF-SV9を使用中。サスペンドからレジュームした際に、タッチパッドの動作が非常に遅くなり、操作不能になります。 ↩︎

VS CodeからDebian on WSL2.0にアクセスできずに焦った話

Mon, 12 Apr 2021 19:29:25 +0000

発生した問題

VS Codeが出力したエラーメッセージは次の通りでした。VS Code Server for WSL closed unexpectedly.と表記されている通り、WSL向けのVS Code Serverへの接続が予期しない理由により切断された、ということです。

[2021-04-12 10:24:41.224] Resolving wsl+debian, resolveAttempt: 1
[2021-04-12 10:24:41.302] Starting VS Code Server inside WSL (Debian)
[2021-04-12 10:24:41.302] Extension version: 0.54.6, Windows build: 19042. Multi distro support: available. WSL path support: enabled
[2021-04-12 10:24:41.302] No shell environment set or found for current distro.
[2021-04-12 10:24:41.510] Probing if server is already installed: C:\Windows\System32\wsl.exe -d Debian -e sh -c "[ -d ~/.vscode-server/bin/08a217c4d27a02a5bcde898fd7981bda5b49391b ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"
[2021-04-12 10:24:41.775] Probing result: found
[2021-04-12 10:24:41.775] Server install found in WSL
[2021-04-12 10:24:41.777] Launching C:\Windows\System32\wsl.exe -d Debian sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" 08a217c4d27a02a5bcde898fd7981bda5b49391b stable .vscode-server 0 '}
[2021-04-12 10:24:41.968] sh: 1: /mnt/c/Users/sonohen/.vscode/extensions/ms-vscode-remote.remote-wsl-0.54.6/scripts/wslServer.sh: Input/output error
[2021-04-12 10:24:41.969] VS Code Server for WSL closed unexpectedly.
[2021-04-12 10:24:41.969] For help with startup problems, go to
[2021-04-12 10:24:41.969] https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips
[2021-04-12 10:24:41.981] WSL Daemon exited with code 0

原因

不明。この事象が発生している時に、Windows TerminalからDebian on WSL2.0にアクセスし、以下のコマンドを発行したところ、エラーが発生した。cdの後にlsが発行されているのは環境によるものである。¹

% cd /mnt
ls: 'c' にアクセスできません: 入力/出力エラーです

解決方法

VS Codeを閉じた後、コマンドプロンプトで以下のコマンドを実行し、その後、再度VS Codeを起動する。

wsl --shutdown

参考にしたサイト

WSL2 cannot access ‘c’: Input/output error

~/.zshrcに、chpwd() { ls -ltr --color=auto }を登録しているため、cd直後にlsコマンドが発行されている。 ↩︎

WSL2で使っているソフトウェア

Tue, 02 Jun 2020 01:08:36 +0000

今のところ使っているアプリケーションは以下の通り。
- GNU Emacs
- tmux
- tig: gitのクライアント
dotfilesの管理も始めた。
Windows Terminalは，Alt+Enterでフルスクリーンになる。
- 上記の環境だと，もはやWindowsなのかLinuxなのか分からないですね。

放送大学大学院の通信指導課題提出結果と今後の作戦について

Sun, 24 May 2020 14:58:21 +0900

履修している科目は以下の通り。

人的資源管理（‘18）
社会的協力論（‘20）

結果は，どちらも満点。人的資源管理については，一部（というか半分）の回答は，テキストを見ながら実施したので当然といえば当然ではある。

社会的協力論は引き続き真面目に受講するとして，人的資源管理については理解が不十分な箇所（特に人的資源管理の歴史や，人事等級・考課制度とモチベーションの関連）があるので，今後，復習を実施していく必要があると認識。復習だからそんなに時間はかからないと思うが，最後にまとめてやろうとすると大変なので，通常の講義の予復習や研究課題レポートの執筆と並行して計画的に進めていくことにしたい。早速，org-modeで管理しているtodo管理表に，「人的資源管理の復習計画を立てること」というタスクを追加した。

終わり。

Windows Subsystem for Linux (WSL) 2への変換

Wed, 20 May 2020 14:37:27 +0900

バージョンの確認

PS C:\Users\sonohen> wsl -l -v

 NAME STATE VERSION
* Debian Stopped 1

変換を試みる

PS C:\Users\sonohen> wsl --set-version Debian 2

変換中です。この処理には数分かかることがあります...
WSL 2 を実行するには、カーネル コンポーネントの更新が必要です。詳細については https://aka.ms/wsl2kernel を参照してください

以下のURLにアクセスして、wsl-update_x64.msiをダウンロードする。

手順 4 - Linux カーネル更新プログラムパッケージをダウンロードする

セットアップが終わったら，再度チャレンジする。

PS C:\Users\sonohen> wsl --set-version Debian 2

変換中です。この処理には数分かかることがあります...
WSL 2 との主な違いについては、https://aka.ms/wsl2 を参照してください
Windows の仮想マシン プラットフォーム機能を有効にして、BIOS で仮想化が有効になっていることを確認してください。
詳細については、https://aka.ms/wsl2-install を参照してください

そもそもの手順を実施していなかったので実施する。

仮想バーチャルマシンサービスのインストール

管理者としてPowerShellを実行する。

PS C:\WINDOWS\system32> dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

展開イメージのサービスと管理ツール
バージョン: 10.0.19041.1

イメージのバージョン: 10.0.19041.264

機能を有効にしています
[==========================100.0%==========================]
操作は正常に完了しました。

WSL2を既定のバージョンとして設定する

PS C:\WINDOWS\system32> wsl --set-default-version 2

WSL 2 との主な違いについては、https://aka.ms/wsl2 を参照してください

これで今後インストールされるWSLはバージョン2となる。

変換する

PS C:\WINDOWS\system32> wsl --set-version Debian 2
PS C:\WINDOWS\system32> wsl -l -v

	NAME STATE VERSION
* Debian Stopped 2

Hugoをインストールする

Wed, 06 May 2020 11:36:53 +0900

Hugoを導入する

$ hugo new site shared/site
$ cd site
$ code config.toml
baseURL = "http://sonohen.github.io/"
languageCode = "ja-JP"
title = "sonohen's tech log"
$ hugo

ここの時点で，publicディレクトリーが作られていることを確認する。

テーマの導入

Hugo Themeにすぐに使えるテーマが掲載されている。

今回は，Hugo Theme Minosを利用する。

$ cd themes/
$ git clone --depth 1 https://github.com/carsonip/hugo-theme-minos
$ code ../../config.toml
theme = "hugo-theme-minos"
paginate = 10
[params]
 smartToc = true
$ hugo

GitHub Pageの設定

blogレポジトリを作る
1. これはprivateレポジトリで良い
sonohen.github.ioレポジトリを作る

Gitの設定

public/は，サブモジュールとして管理する。レポジトリが別なため。

git submodule add -b master git@github.com:sonohen/sonohen.github.io.git public

以下のエラーではまったでござる。

$ git submodule add -b master git@github.com:sonohen/sonohen.github.io.git public
A git directory for 'public' is found locally with remote(s):
origin https://github.com/sonohen/sonohen.github.io.git
If you want to reuse this local git directory instead of cloning again from
git@github.com:sonohen/sonohen.github.io.git
use the '--force' option. If the local git directory is not the correct repo
or you are unsure what this means choose another name with the '--name' option.

この場合，古いsubmodule情報が".git/“以下に残っていることが原因なので，以下のディレクトリとファイルの中身を確認して，古いファイルを削除してやる必要がある。

.git/modules/
.git/config

こうならないためには，以下のようにsubmoduleを削除しましょう。

git submodule deinit <消したいsubmodueへのパス>
git rm <消したいsubmoduleへのパス>

Visual Studio Codeを設定して記事を書く

Hugofy（akmittal.hugofy）をインストールする。
Hugofy: New Postを選択する。
記事を書く。
Hugofy: Buildを選択する。
siteとpublicをcommit&pushする。

参考

[git]git submodule addでエラー「A git directory for ‘[指定モジュール]‘ is found locally with remote(s):」

sonohen's tech blog

Google Pixelのデスクトップモードでブログを書いてみるテスト

Claude CodeでオウンドメディアのAI編集部を立ち上げてみた

TL;DR

なぜAI編集部を作ろうとしたのか

.claudeの構成

人間が定義するもの

AIが実装したもの

実際のところ、どうだったか

問題1: 編集長の承認条件が厳しすぎてコンテキストを食い潰した

問題2: 執筆された記事が似非マーケターが書いたような内容になった

実際に出力された記事

学んだこと

次にAIエージェントを立ち上げるときに考えておきたいこと

まとめ

ZettelkastenをRAGの情報源として有効活用するには、ノート間のリンクに型付きエッジを持たなければならない

TL;DR

なぜ、ノート間（リンク）の関係を自動抽出ではなく手動で行うのか（はじめに）

きっかけ

ZettelkastenとRAGの相性問題

リンクの「意味」は、人間は理解でき、AIには理解できない

データの意味付けを後回しにしてきた歴史

(1) セマンティックウェブ

(2) ビッグデータ

(3) 企業におけるRAG活用

型付きエッジを付与したリンクの提案

制約付きグラフ探索の効果を計測する

コンテキスト膨張は実害を生む

課題

まとめ

「顧客はわかっていない」を構造的に再解釈する

TL;DR

きっかけ

思考限界というフレームワーク

アーキテクトの役割：思考限界をずらす

AIとの協働に見る、同じ構造

思考限界を動的にずらすことに成功した例

OpenShift： 「強制」という制約が自由をもたらす

Porsche Informatik： 「枠」が組織のしがらみを溶かす

「構造設計能力」という自己研鑽の方向性

まとめ

Red Hat OpenShiftのDeveloper SandboxをAWSと比較しながら触ってみた

TL;DR

きっかけ

Platform as a Service vs Platform as a Product

Developer Sandboxで試したこと

Lightspeedとの統合

Gitからのデプロイ

ログとターミナルの統合

リソースの可視化

AWSとの比較: 閉域網要件

導入事例から読み解く

Porsche Informatik：6週間でのレガシー移行

JRA（日本中央競馬会）：5000万PVの動的スケーリング

まとめ

ローカルLLMのtemperatureとseedが生成品質に与える影響と「推論言語」の関係

TL; DR

きっかけ

実験環境

機材等

パラメータ

実験①： プログラムコードを生成する（FizzBuzz）

プロンプト

temperature = 0 （決定的）

temperature = 0.3 （やや多様）

temperature=1.2（多様）

コード生成の観察まとめ

実験②： 俳句を生成する

temperature = 0 （決定的）

temperature = 0.3 （やや多様）

temperature = 1.2 （多様）

俳句生成のまとめ

加えて、見落としがちな変数としての推論言語

パラメータ設定の指針

結果を収束させたい場合（プログラミング）

多様性を出したい場合（創作系タスク）

まとめ

今後の課題

ローカルLLMでSpec Driven Developmentは、まだ難しかった

TL; DR

`.claude`の構成

OpenShift：「強制」という制約が自由をもたらす

Porsche Informatik：「枠」が組織のしがらみを溶かす

実験①：　プログラムコードを生成する（FizzBuzz）

実験②：俳句を生成する