hdknr blog

SQLite の「unable to open database file」が高負荷時刻に散発する問題を WAL 化で根治した話 ある自立型トレーディングシステムの運用中に、SQLite が OperationalError: unable to open database file を散発的に投げる慢性バグを追い詰めて修正した記録です。「ディスクは空いている」「ファイルは存在する」のにエラーが出る、という一見矛盾した現象の正体と、その根治・緩和の二段構えの対策をまとめます。 WAL とは? 本題に入る前に、今回のキーになる WAL（Write-Ahead Logging） を簡単に押さえておきます。 SQLite には書き込み中のクラッシュからデータを守るための「ジャーナル方式」が複数あり、journal_mode PRAGMA で切り替えます。 delete（デフォルト） — ロールバックジャーナル方式。トランザクションを開始するたびに 元DB-journal というファイルを新規作成して変更前の内容を退避し、コミット時に削除する。書き込み中は DB 本体を直接書き換えるため、読み取りと書き込みが互いをブロックする。 WAL — 先行書き込みログ方式。変更を DB 本体ではなく追記専用の 元DB-wal ファイルに追記していき、後で「チェックポイント」で本体に反映する。-wal と -shm（共有メモリインデックス）は一度作られたら使い回されるため、トランザクション毎のファイル新規作成が発生しない。 WAL の主な利点: 特徴 効果 読み書きが互いをブロックしない reader はトランザクション中の writer を待たずに読める（その逆も） ジャーナルファイルを毎回作らない ファイル作成のオーバーヘッドと競合がなくなる 書き込みが概ね高速 fsync 回数を減らせる（特に synchronous=NORMAL 併用時） WAL が向いているケース: 読み取りが多く・書き込みもそれなりにある、同一ホスト上の単一プロセス／複数プロセスからのアクセス。今回のように「書き込みデーモン 1 つ＋複数の reader」という構成は典型的な適用例です。 WAL の注意点: ① ネットワーク越しのファイルシステム（NFS など）では共有メモリが使えず非対応、② in-memory DB では効かない、③ -wal / -shm ファイルが DB 本体と併存するため、バックアップは単純な cp ではなく専用 API（後述）を使う必要がある。 ...

LINE 公式アカウントで集客し、HubSpot でリード管理する——この組み合わせを使っている企業は多いはずです。しかし両者のユーザーデータは放っておくと分断されたままです。本記事では、LINE で配布したアンケート LP の回答者（HubSpot リード）と、LINE 友だち（userId）を自動で紐づける仕組みを、追加サーバーなし・HubSpot ネイティブ機能 + LIFF だけで構築する方法を解説します。 課題: LINE 友だちとリードは「別人」のまま LINE 公式アカウントの友だちは LINE 上の userId でしか識別できず、HubSpot のコンタクトはメールアドレスをキーに管理されます。アンケート LP の URL を LINE で配って回答を集めても、そのままでは 「この回答者は LINE のどの友だちなのか」が分からない 「友だちのうち誰が回答済み/未回答か」のセグメントが作れない HubSpot のリスト起点で LINE Push 配信ができない という状態になります。紐づけの鍵は、フォーム送信時に LINE の userId を一緒に HubSpot へ渡すことです。 方式比較 userId をフォームに同乗させる方法は主に 3 つあります。 方式 仕組み 配信方法 確実性 ① LIFF（推奨） LP を LIFF アプリとして開き、SDK で userId を取得 → hidden フィールドで同送 ブロードキャスト可（全員同じ URL） 高 ② パーソナライズ URL ユーザーごとに ?t=<トークン> 付き URL を Push 送信。トークン↔userId の対応表をサーバーで保持 Push のみ（個別配信・通数コスト増） 中（URL 転送リスク） ③ LINE Login LP に「LINE でログイン」ボタンを設置 自由 高（ただし回答前に同意画面が挟まり離脱要因） 「全員に同じ URL をブロードキャストで配れて、ユーザー操作ゼロで userId が付いてくる」のは LIFF だけです。アンケート用途なら実務上ほぼ一択と言えます。 ...

HubSpot を運用していると必ず直面するのが重複リード（コンタクト）の問題です。同じ人がフォーム経由とインポート経由で別レコードになっている、表記揺れで名寄せされていない——こうした重複を放置するとメール配信もスコアリングも狂います。 結論から言うと、API を使って 2 つのコンタクトをマージすることは可能です。HubSpot の API にはコンタクトのマージ用エンドポイントが用意されており、マージ機能自体は Starter プランでも利用できます（API 実行には Private App の作成権限 = Super Admin が必要）。 ただし、「AI エージェントだけで全自動で重複を検知・マージまで完結させる」のは、安全性の観点から少しハードルが高いです。マージは一発勝負でやり直しが効かないからです。 現実的かつ賢いやり方は、「AI に重複を見つけさせてリスト化させ、マージ自体は API で行う（または人間が承認する）」というシステムを組むことです。本記事では具体的な仕組みと API の実装方法を解説します。 AI × API で実現する「自動重複マージ」の設計図 全自動で裏でマージしてしまうと、同姓同名の別人（例:「佐藤一郎」さんという別の会社の人）をマージしてしまうリスクがあります。そのため、以下のような 3 ステップの仕組みを作るのが一般的です。 Step 1: AI が検知 — AI（またはスクリプト）が「名前が一致、かつ会社名や電話番号が類似」しているリードを抽出 Step 2: 人間が確認 — Slack や社内ツール、Google スプレッドシート等に「この 2 人、マージして大丈夫ですか?」と AI が通知 Step 3: API で実行 — 人間が「承認（OK）」ボタンを押したら、システムが HubSpot API を叩いて安全にマージを実行 Step 1「AI が検知」を分解する 「AI が検知」は実際には 4 つの工程に分かれます。すべてを LLM にやらせるのではなく、機械的に絞り込めるところはスクリプトで処理し、あいまいな判断だけを LLM に渡すのがコストと精度のバランスを取るコツです。 ...

Claude Code でコーディングする時間が増えると、ふと気づくのが「VSCode って、けっこうメモリを食うな」という事実です。プロジェクトを 5 つも同時に開けば、エディタだけでメモリがカツカツになります。 note の記事「GhosttyをVSCodeみたいにしよう！」（Naoki | 電電猫猫 氏）では、まさにこの悩みを起点に、高速なターミナルエミュレータ Ghostty の上に VSCode 風の開発環境を再現する構成が紹介されていました。本記事ではその考え方を整理しつつ、使われている TUI ツール群を補足して紹介します。 なぜターミナルで VSCode を再現するのか VSCode の基本的な画面構成はだいたいこうなっています。 左サイドバー：ファイル一覧と Git のツリー表示 右側メイン：エディタ（または Claude Code）と、その下にターミナル 便利な一方で、Electron ベースの VSCode は 1 ウィンドウあたりのメモリ消費が大きく、プロジェクトを並行して開くほど重くなります。そこで「同じレイアウトを、軽量なターミナル上で組めないか？」という発想に至ります。 Ghostty は Mitchell Hashimoto 氏が開発する GPU アクセラレーション対応のターミナルエミュレータで、標準で画面分割（split）機能を持っています。この分割機能と、小さな TUI ツールを LEGO のように組み合わせることで、VSCode のレイアウトをそのまま再現するというのが今回のアプローチです。 前提：以降の手順は Rust の cargo と Ghostty がインストール済みであることを前提にしています。FileTree・keifu・zellij はいずれも cargo install で導入できます。 各パーツの役割は次のとおりです。 サイドバー（細い列）：上に FileTree、下に keifu メイン領域（広い列）：上に Claude Code / エディタ、下に ターミナル 高頻度で触るプロジェクトは zellij のセッションとして保存しておく FileTree — VSCode 風のファイルツリー TUI FileTree は、VSCode のファイル一覧をターミナル上で模倣した TUI ファイルエクスプローラです。記事の著者（電電猫猫 氏 = Naoki Takahashi 氏）自身が作ったツールで、Vim キーバインドに対応した高速・軽量なファイルブラウザになっています。 ...

はじめに X（旧 Twitter）でこんな投稿が流れてきました。 【衝撃】Claude Code でとんでもないモードが解禁👀 Opus 4.8 ＋ /ultracode で有効になる新機能「Dynamic Workflows」！ ・タスク難易度を自動検知 ・オーケストレーション用スクリプトを生成 ・複数エージェントに役割分担 ・検証フローまで自動構築 ・エージェントスウォームで並列実行 つまり開発フローの全工程を Claude が自走。 「人間はゴールを投げるだけ、Claude Code が PM ＋ 開発チームを自動編成して並列実行する」——確かにインパクトのある話です。 ただ、こういうバイラル投稿は機能を過度に一般化しがちです。本記事では、/ultracode と Dynamic Workflows の実体を公式ドキュメントと実機の挙動から整理します。そのうえで「本当に変わること」と「誇張されていること」を切り分けます。結論から言うと、機能はほぼすべて実在しますが、“完全自動” ではありません。 Dynamic Workflows とは何か Dynamic Workflows は、Claude Code が複数のサブエージェントを JavaScript スクリプトで決定論的にオーケストレーションする機能です。現在は research preview（研究プレビュー）として提供されています。 ポイントは「決定論的」という部分です。通常のエージェントはモデルが自分の判断で次の手を決めますが、Workflow ではループ・分岐・ファンアウト（並列展開）といった制御フローをスクリプトで明示的に記述します。「何を並列にやるか」「何を検証するか」「何を統合するか」を人間（あるいは Claude）がコードとして固定できるわけです。 スクリプトは export const meta = {...} で始まり、本体で以下のような構成要素を使います。 phase(title) — フェーズ（工程）を区切る agent(prompt, opts) — サブエージェントを 1 体起動する parallel(thunks) — 複数タスクを並列実行する（全完了を待つバリア） pipeline(items, stage1, stage2, ...) — 各アイテムを複数ステージに流す（ステージ間でバリアなし） これらは実際の Workflow ツールが提供する API です。最小の例を見てみましょう。 ...

gh（GitHub CLI）は通常、gh auth login の対話的なブラウザフローで認証します。しかし CI/CD パイプライン、共有サーバー、使い捨てコンテナのような ブラウザもキーボード入力もない環境 では、その対話フローは使えません。 こうした「ヘッドレス（非対話）」環境では、アクセストークン（パーソナルアクセストークンなど）を環境変数で渡す ことでクローンを自動化できます。本記事では、推奨される認証パターンと、その際に陥りがちな落とし穴・セキュリティ上の注意点を整理します。 なお、本記事を書く過程で「gh auth token --web でトークン生成画面を開ける」という情報を検証したところ、そのようなフラグは存在しませんでした。よくある誤情報なので、後半で正しい代替手段とあわせて解説します。 方法1：環境変数 GH_TOKEN を使う（最もおすすめ） gh は、環境変数 GH_TOKEN（または GITHUB_TOKEN）にトークンが設定されていると、それを自動的に認証に使用します。gh auth login のような状態の保存を一切行わないため、自動化環境に最も適しています。 一時的にトークンを渡してクローンする場合は、1 行で実行できます。 1 GH_TOKEN=ghp_YourTokenHere gh repo clone owner/repo gh auth login --help のドキュメントにも、 Alternatively, gh will use the authentication token found in environment variables. This method is most suitable for “headless” use of gh such as in automation. と明記されており、自動化での利用は GH_TOKEN が公式推奨です。 ...

AIエージェントが業務システムに本格導入される時代に入り、「FDE（Forward Deployed Engineer）」というエンジニア職種が改めて注目を集めています。AIエージェントを現場の業務フローに組み込み、「成果が出るまで」を一気通貫で推進する役割です。なぜ今このモデルが再評価されているのか、その役割と重要性を整理します。 FDE（Forward Deployed Engineer）とは FDEは「フォワード・デプロイド・エンジニア（前線配備型エンジニア）」の略です。Palantir が2011年に考案したモデルで、エンジニアを顧客環境に直接埋め込む形で生まれました。AIエージェントの実用化が加速する中で、この働き方が改めて脚光を浴びています。 役割の核心 FDEは開発拠点に留まらず、顧客や社内の業務現場に深く入り込みます。AIエージェントを実際の業務フローに組み込み、「成果が出るまで」を一気通貫で推進することが役割の核心です。 従来のソフトウェアエンジニアとの違いは「配備場所」にあります。FDEは現場の業務担当者と並走しながらAIシステムを実装・調整します。 なぜ今重要なのか AIエージェントは「自律的にタスクを推論して実行する」という強力な特性を持っています。しかし、以下のような課題から、現場での機能不全が起きがちです。 業務ルールの複雑性: 現場の暗黙知や例外ルールをAIに正しく反映するのは困難 人間との役割分担設計: どこまでをAIに任せ、どこから人間が承認・介入するかの線引き 段階的な信頼構築: いきなり全自動化するのではなく、徐々にAIへの委任範囲を広げるプロセス管理 FDEは「現場とAIエージェントの橋渡し」を担うコア人材として必要とされています。技術力だけでなく、業務理解力・コミュニケーション力・推進力を兼ね備えることが求められます。 なぜAIではとくに「現場常駐型」が要るのか 従来の業務システムは「仕様通りに動くこと」が正解でした。これに対しAIは、データの質や現場の環境条件に大きく依存するという性質を持ちます。 現場の熟練者が持つ暗黙知はデータ化されていない 需要予測AIは入力データの欠損に左右される 画像認識（カメラ）AIは照明などの環境条件で精度が変わる これらの要素は、会議室や開発拠点にいるだけでは把握できません。FDEは現場に身を置くことで、開発と現場のあいだに生じる時間差・認識差を最小化します。違和感が出たらその場で修正し、翌日には改善版を届ける——この高速なフィードバックループこそが、AIを「実験」から「現場で使える戦力」へと進化させます。 従来のITコンサル・SEとの違い AI推進体制を検討すると、FDEはITコンサルタントやシステムエンジニア（SE）と混同されがちです。しかし主戦場も付加価値も異なります。AIプロジェクトでは「最初から正解の仕様が存在しない（都度、仕様が変わっていく）」ことが一般的で、FDEは仮説検証を短いサイクルで回しながら最適解を探索する点が決定的に違います。 観点 ITコンサルタント 従来のSE／ベンダー FDE 主な役割 戦略立案・要件定義 仕様書に基づく開発・保守 現場課題の特定と即時実装・定着 主戦場 会議室（経営・管理層） 開発拠点（リモート中心） 現場（フロントライン） 開発手法 設計書作成が中心 ウォーターフォール型 超高速アジャイル・プロトタイピング 付加価値 論理的な正解の提示 安定したシステムの構築 現場での実用性とROIの最大化 FDEが現場で担うこと AIエージェント導入の現場では、FDEは次のような多面的な役割をこなします。 フェーズ FDEの仕事 要件把握 現場に入り込み、暗黙知や例外ルールを含む業務フローを理解する 実装・調整 AIエージェントを実際の業務システムに組み込み、現場のデータで動かす ガードレール設計 どこから人間が承認・介入するか（Human-in-the-loop）の線引きを設計する 信頼構築 委任範囲を段階的に広げ、現場が安心してAIを使える状態をつくる ポイントは、単にAIにタスクを委任して終わりにしないことです。人間が最終判断するガードレールを設計し、職員・現場担当者が自らAIワークフローを調整できる仕組みを残すことが、定着するAIエージェント導入の条件になります。 高リスク環境ほど価値が出る 審査・規制・安全監視のような「間違いが許されない」高リスク業務ほど、いきなりの全自動化はできません。だからこそ、現場の複雑なルールを理解しながらAIを少しずつ組み込み、人間の監視を組み込んだ形で運用に乗せていくFDEの役割が効いてきます。段階的な導入とガードレール設計こそが、こうした環境でのAI活用を成功させる鍵です。 なぜ今、FDEが求められるのか AI投資が活発化するなか、FDEが戦略的に重要視される理由は大きく3つあります。 「使われないAI」を防ぎ、ROIを最大化する: AI導入の最大リスクは、数千万円規模の投資をしても現場で使われなくなることです。「入力が煩雑」「通知が遅い」「画面が見づらい」——こうした小さな不満がAI定着を阻みます。FDEは現場ユーザーの声を即座に反映し、UI/UXをその場で改善します。 データ品質の課題を現場で解決する: AIの精度はデータに依存しますが、基幹システムのデータが現場の実態を正確に反映していないケースは少なくありません。FDEはデータ生成のプロセスを現場で確認し、必要なら収集方法や入力フロー自体を再設計します。 意思決定から実装までのリードタイムを短縮する: 「現場要望 → 実装 → テスト → 改善」のサイクルが、数週間単位から数日、場合によっては数時間単位へと短縮されます。このスピードがDX推進の成否を左右します。 FDEに求められる3つのスキル FDEとして成果を出すには、技術と業務をまたぐ複合的な力が求められます。 ...

2026年5月11日に一般提供（GA）となった Claude Platform on AWS のセットアップ手順・API 呼び出し・inference_geo の挙動を実機で検証した記録です。 概念的な概要や Amazon Bedrock との比較についてはこちらの記事をご参照ください。本記事では hands-on のセットアップと API 呼び出しに絞って解説します。 参考: Claude Platform on AWS がGA。セットアップとAPI呼び出しを試してみた | DevelopersIO Claude Platform on AWS とは（概要） AWS アカウントを通じて Anthropic のネイティブ Claude Platform に直接アクセスできるサービスです。Amazon Bedrock とは別サービスで、推論は Anthropic のインフラ上で実行されます。 項目 Claude Platform on AWS Claude on Bedrock 推論の実行 Anthropic AWS 利用可能な機能 全ネイティブ機能（Skills, Code Execution, Files API, MCP 等） Bedrock が提供する機能（Guardrails, KB, Converse API 等） 新機能の利用 Anthropic と同日 AWS が対応したとき 認証 AWS IAM AWS IAM 監査ログ CloudTrail CloudTrail 課金 AWS 請求に統合 AWS 請求に統合 向いているケース 最新機能・エージェント・スキル データ所在地優先・FedRAMP/HIPAA 等のコンプライアンス対応・AWS 単独データ処理要件 セットアップ手順 1. AWS コンソールで開始 AWS マネジメントコンソールで「Claude Platform on AWS」を開き「Get Started」をクリックします。確認画面で「Continue」を選択します。 ...

grill-me とは何か mattpocock/skills は、Total TypeScript で知られる Matt Pocock が自分の ~/.claude/skills/ から実際に使っている 23 本のスキルをそのまま公開したリポジトリだ。「教材向けに整えた」ではなく「本番運用している実物」というのが特徴で、X（旧 Twitter）でも注目を集めている。 その中でも最も人気が高いのが /grill-me だ。スキルの定義は英文 4 文だけ。しかしこの短さが本質で、「コードを 1 行も書く前に AI があなたを徹底的に詰める」という仕組みを実現する。リポジトリには engineering・productivity・misc の 3 カテゴリにわたる 18 本以上のスキルが収録されている。 実際のスキル定義（skills/productivity/grill-me/SKILL.md）は次のとおり： 1 2 3 4 5 6 7 Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask the questions one at a time. If a question can be answered by exploring the codebase, explore the codebase instead. なぜ「詰め」が必要なのか 生成 AI にコードを書かせる際の最大の落とし穴は、曖昧なまま走り出すことだ。「なんとなくこういうのを作りたい」で投げると、それらしいコードは出てくるが、後から要件とのズレが発覚して作り直しになる。 ...

株式投資の世界で「いいタイミングで買いたい」と考えたとき、真っ先に出てくる戦略のひとつが 押し目買い です。英語では “Buy the Dip” と呼ばれ、世界中のトレーダーが日常的に意識している王道の手法です。 この記事では、押し目買いの基本概念・メリット・リスク・見極め方を解説します。 押し目買いとは 押し目買い（おしめがい） とは、上昇トレンドにある株価が一時的に下がったタイミング（調整局面）を狙って買いを入れる投資手法です。 株価は一本調子で上がり続けるわけではなく、上昇と小幅な下落を繰り返しながら右肩上がりに推移します。その「小幅な下落」こそが 押し目 であり、そこを狙って参入するのが押し目買いです。 山登りに例えると、次の急斜面に備えて一息ついている「踊り場」で合流するイメージです。 押し目が生まれるメカニズム 押し目が発生する典型的な流れは以下のとおりです。 株価が大きく上昇する 利益を確定させたい投資家の 利益確定売り が集まり、一時的に価格が下落する（＝押し目） 「安くなった」と判断した新たな買い手が参入し、再び上昇に転じる この「3」の動きが確認できれば、押し目での買いが成功したことになります。 メリットとリスク 押し目買いにはメリットが多い反面、特有の難しさもあります。 メリット リスク（注意点） 割安で購入できる：上昇トレンドの途中にある株を、直近の高値より安い価格で取得できる 「落ちてくるナイフ」になる危険：一時的な下落だと思ったら、そのままトレンドが転換して大きく下落するケースがある 損切りラインを決めやすい：直前の安値を下回ったら損切りするという明確なルールが立てやすい 判断が難しい：「一時的な調整」なのか「トレンド終焉の始まり」なのかの見極めには経験が必要 代表的な押し目の見極め方 投資家はテクニカル指標を使って「そろそろ反発するタイミング（押し目）」を判断します。以下は代表的な手法です。 移動平均線（MA） 25日移動平均線や75日移動平均線まで株価が下がってきてタッチしたタイミングは、押し目として注目されやすいポイントです。移動平均線は多くの投資家が参照するため、そこで反発が起きやすい 自己実現的な性質（多くの人が同じ指標を見て同じ行動をとるため、予測が現実になりやすい）があります。 一目均衡表の「雲」 一目均衡表は日本発のテクニカル指標で、相場のトレンドや支持・抵抗帯を視覚的に把握できます。その中心的な要素である「雲」は、株価の支持帯・抵抗帯として機能します。 株価が一目均衡表の「雲（支持帯）」の上端付近にサポートされたタイミングは、押し目として判断する根拠になります。 心理的節目（きりの良い数字） 1,000円・5,000円・10,000円といったキリの良い価格帯は、多くの投資家が意識するため、そこで反発が起きやすい傾向があります。 「押し目待ちに押し目なし」という格言 「安くなったら買おう」と待っていると、株価が全く下がらずにどんどん上がってしまう この格言は、押し目買いの難しさを端的に表しています。 完璧なタイミングを狙いすぎると、機会を逃してしまう。一方、焦って飛び込むと押し目ではなく天井をつかむ結果になる。その葛藤を乗り越えるためには、事前に明確な判断基準（エントリールール）を決めておくこと が重要です。 まとめ ポイント 内容 定義 上昇トレンド中の一時的下落（押し目）で買いを入れる手法 英語名 Buy the Dip 最大のメリット 割安なエントリー価格と損切りラインの明確化 最大のリスク 押し目に見えてトレンド転換（落ちてくるナイフ）になる可能性 見極めに使う指標 移動平均線・一目均衡表の雲・心理的節目 押し目買いは「シンプルだが奥深い」戦略です。テクニカル指標を組み合わせながら、自分なりのエントリールールを磨いていくことが、長期的な収益につながります。