# 株式会社KDOT

> コーポレートサイトとエンジニアリングブログ（KDOT Engineering）。各記事は URL 末尾に .md を付けると Markdown 本文を取得できる。

## コーポレート

- [ホーム](https://kdot.co.jp/): 株式会社KDOTのコーポレートトップ
- [サービス](https://kdot.co.jp/services): KDOT のサービス。ソフトウェア開発で経営・事業の課題への解決策をご提案し、ビジネスオペレーションで業務・プロセス・システムを量・質・範囲・構造の 4 つの軸で強化します。
- [会社情報](https://kdot.co.jp/company): 会社概要・所在地
- [お問い合わせ](https://kdot.co.jp/inquiry): 一般のお問い合わせ
- [営業のお問い合わせ](https://kdot.co.jp/inquiry/sales): 営業・提案のご相談
- [フィロソフィー](https://kdot.co.jp/philosophy): ミッション・ビジョン・バリュー
- [プライバシーポリシー](https://kdot.co.jp/privacy): 個人情報の取り扱い
- [事例](https://kdot.co.jp/works): 開発支援・技術顧問・データ活用の事例一覧

## ソフトウェア開発事業

- [事業企業向け](https://kdot.co.jp/services/software-development/for/business-companies): 経営・事業課題を技術で解く支援
- [技術企業向け](https://kdot.co.jp/services/software-development/for/tech-companies): 技術を事業成長につなげる支援
- [ソフトウェア開発](https://kdot.co.jp/services/software-development): ソフトウェア開発事業のトップ。顧客セグメントとサービスの一覧
- [データ分析](https://kdot.co.jp/services/software-development/data-analysis): データ分析サービスの紹介
- [データ基盤](https://kdot.co.jp/services/software-development/data-platform): データ基盤構築サービスの紹介
- [PdM 支援](https://kdot.co.jp/services/software-development/pdm): プロダクトマネジメント支援の紹介
- [セキュリティ診断・対策](https://kdot.co.jp/services/software-development/security): 情報漏えいや不正利用で事業が停止する前に、私たちがお客様のサイトやシステムの弱点を修正する。
- [プロダクト / Web システム開発](https://kdot.co.jp/services/software-development/web-system-dev): 要件定義から本番運用までのプロダクト開発支援の紹介

## ビジネスオペレーション事業

- [ビジネスオペレーション](https://kdot.co.jp/services/business-operation): 営業や受発注、製造や物流、顧客対応、管理部門の業務まで。企業が価値を創出するための日々の活動を、KDOT が整理して仕組みに転換します。目標は、件数が増加しても人員を追加せずに処理でき、担当が交代しても品質が変わらない業務です。
- [バックオフィスの無料相談窓口](https://kdot.co.jp/services/business-operation/consult): 経理・労務の業務分析・業務定義、業務プロセス標準化、システム化・DX、組織・要員設計、運用設計・定着支援の相談窓口

## 事例

- [新サービス公開前のセキュリティ診断と修正](https://kdot.co.jp/works/pre-launch-security-check): 不動産の分野で事業を拡大する会社は、新サービスを公開する前に、悪用されうる弱点を解消できました。診断の結果を根拠に取引先へ安全を説明できる状態で、新サービスを公開しています。診断は開発支援会社の KDOT が担当し、修正はサイトによって KDOT と各サイトの開発会社が分担しました。
- [基盤システムのセキュリティ常時監視と対策](https://kdot.co.jp/works/security-without-specialists): 人材サービスの会社は専門の人材を採用せずに、自社のシステムの安全の状態を把握できるようになりました。同社は業務の基盤システムを開発会社に発注しており、社内にエンジニアはいません。開発支援会社の KDOT はこの開発会社の下で開発に参加し、クラウドの状態を仕組みで常に自動点検する常時監視を、機能の開発と並行して導入しました。そのうえで常時監視が検出した 200件を超える指摘に対応し、件数と対応の計画を開発会社経由で同社に報告しました。監視と対応は現在も KDOT の担当です。
- [過去実績を提案に活用する分析の仕組み](https://kdot.co.jp/works/data-backed-creative-proposals): 広告代理店との取り組みです。同社は過去実績の示唆を次の提案へ反映し、結果をどのように予測したか、その背景まで提案先のクライアントへ説明できるようになりました。KDOT は案ごとの見込みと判断材料を比較できる仕組みを業務アプリとして実装しました。さらに業務アプリの中核となる処理ロジックと機械学習モデルについて、特許手続きを担う弁理士が技術の新規性や工夫を検討するための資料を作成しました。その後この発明には特許が付与されました。
- [効果検証の分析処理基盤](https://kdot.co.jp/works/effect-measurement-platform): 効果検証を提供する分析会社との取り組みです。同社は分析者の人数に比例してしか売上と利益を伸ばせない事業の形を、効果検証をプロダクトとして提供することで変革しようとしていました。手法とモデルは同社のまま、社内では開発できなかった、データと機械学習の重い推定を製品として動かす仕組みの開発を、開発支援会社の KDOT に任せました。推定を案件ごとの手作業ではなくシステムで実行できるようになったことで、同社は人数に比例しない形で売上と利益を伸ばすことを目指せるようになりました。
- [AI の開発会社がプロダクト開発へ事業の幅を広げる](https://kdot.co.jp/works/expanding-into-product-development): AI を主力とする開発会社との取り組みです。同社にはプロダクト開発の引き合いがありましたが、大規模な開発の経験も、中核の技術を担当できる人もいませんでした。KDOT は技術顧問として、アプリケーション基盤と中核の技術を用意し、エンドクライアントとのプロジェクトの進め方も並走しながら伝えました。同社は海外市場向けの単発ワークのマッチングサービスを受託し、数億円規模の開発を公開まで完走しました。これで同社が受託できる範囲は、AI からプロダクト開発まで拡大しました。
- [現場が使うデータ分析の環境](https://kdot.co.jp/works/field-led-data-analysis): 不動産・宿泊領域の新規事業会社との取り組みです。同社では Web の計測データや公開データ、日々の業務で発生するデータを蓄積していましたが、それぞれが分散しており、改善策や同社の顧客への提案を検討する材料にできませんでした。開発支援会社の KDOT は、Web 計測、広告、検索のデータを分析用の基盤へ集約し、サイトを横断する指標の計算規則を統一しました。さらに対話型 AI（人工知能）の Claude から Metabase のデータを照会できるようにしました。現場担当者は、事業全体から地域や物件、Web 上の行動へ確認範囲を絞り込み、自分の問いに即して比較条件を変更しながら、次の施策や同社の顧客への提案を検討できるようになりました。
- [広告クリエイティブ予測 AI の MLOps 基盤](https://kdot.co.jp/works/ml-operations-grand-design): 広告クリエイティブの良し悪しを予測する AI を、自社プロダクトとして提供する企業との取り組みです。同社には推論の精度を評価する基盤がなく、改善が手探りで進み、現在のモデルが十分な水準に達しているかを把握しにくい状態でした。開発支援会社の KDOT は、機械学習のモデルを学習からリリースまで継続的に改善する基盤（MLOps 基盤）を設計し、同社のエンジニアがそれを自ら実装しました。導入後、同社は実験の計画からデプロイまでを効率よく進められるようになり、新たなモデルの出来を見極めたうえで改善を自分たちの手で継続しています。
- [工場向け電力見える化製品の開発](https://kdot.co.jp/works/power-visibility-as-product): 製造業向けにソフトウェア製品を提供する企業との取り組みです。同社は工場の電力を見える化する機能を製品に追加したいと考えていましたが、社内の開発者だけでは手も知見も不足していました。電力計の接続から、データを工場の判断に活用できる形にするところまでを開発支援会社の KDOT に一括で委託し、同社は着手から約 4 か月でこの機能を製品に追加して工場へ販売できるようになりました。納品後の約 9 か月は KDOT が運用を担い、支援が終了した現在は同社が自ら運用を継続しています。
- [価格設定モデルのデプロイ基盤](https://kdot.co.jp/works/pricing-model-deployment): 広告枠の価格設定モデルを開発する分析会社との取り組みです。分析会社はこのモデルを、アドネットワークを運営する配信事業者に提供しています。配信事業者は、自社の環境で自社のデータと統合して分析し、新たなモデルを自ら検証できるようにしたいと考えていました。それにはモデルを配信事業者のシステム上で稼働させる基盤が必要でしたが、分析会社はそれを社内で開発できませんでした。KDOT は分析会社側のチームに参画し、この基盤をチームで設計・構築しました。分析会社はモデルを分析結果として納品するだけでなく、稼働させる基盤まで含めて納品できました。同時に、社外からの要望に応じてモデルを相手の環境へデプロイできる基盤を自社の資産にできました。分析会社はこの基盤を継続的に提供するサービスも配信事業者に提案しています。
- [販促施策の実績分析システム](https://kdot.co.jp/works/promotion-results-analysis): 販促物の制作と効果測定を手がける会社との仕事です。同社には 500 件を超える施策の実績データが溜まっていましたが、提案の場で活用できる形になっていませんでした。
- [マルチプロダクトの共通認証基盤](https://kdot.co.jp/works/shared-auth-platform): 業務向けソフトウェアを提供する企業との取り組みです。同社はプロダクト共通の認証基盤の内製を開始しましたが、技術的な難しさから着手直後に断念しました。開発支援会社の KDOT はその開発を引き継ぎ、共通基盤を設計しました。AWS の認証サービスである Amazon Cognito による認証とトークン発行に、Go で実装した独自の認可サービスを組み合わせた構成です。現在は同社の 10近いプロダクトがこの基盤を共通で利用し、新たなプロダクトを追加するたびに認証を再構築する必要がなくなりました。KDOT は統括するチームでこの複雑な基盤を開発し、その上で機能追加と運用保守を数年にわたって継続しています。
- [金融システムの中核開発](https://kdot.co.jp/works/team-ready-financial-system-development): 金融機関向け資産運用システムを開発する企業との取り組みです。同社は性能とセキュリティに高い要件を有するシステムを、複数のエンジニアで開発していました。開発支援会社の KDOT が担ったのは、アプリケーションの実行を支える機能と、複数の機能で利用する中核処理です。技術的な難所は調査から解決まで担当し、意思決定履歴として社内に蓄積しました。またクライアント企業の力を底上げするため、我々の問題解決が会社内で再現可能になるように勉強会も実施しました。これにより、担当者を増員しても全体の整合性を維持し、エンジニアのインプットが線形にスケールする状態を実現しました。

## 用語集

- [ビジネスサイドのための IT 用語集](https://kdot.co.jp/handbook/glossary): システム開発や業務の仕組みづくりで直面する課題について、解決の前提知識となる IT 用語を解説しています。
- [開発手法・プロセスの用語](https://kdot.co.jp/handbook/glossary/categories/development-process): 要件を決め、見積もり、契約し、検収して運用に移す。発注側が各段階で判断するための語を集めました。
- [システム構成の用語](https://kdot.co.jp/handbook/glossary/categories/system-architecture): システムをどの部品に分け、どうつなぐか。全体像と構成要素を捉え、変更の影響を読むための語を集めました。
- [クラウド・インフラの用語](https://kdot.co.jp/handbook/glossary/categories/cloud-infrastructure): どこに何を置き、誰が運用し、いくらかかるか。基盤の選択と運用の判断に必要な語を集めました。
- [データ・分析基盤の用語](https://kdot.co.jp/handbook/glossary/categories/data-platform): データを集め、整え、使える形で届ける。分析や意思決定の土台を設計するための語を集めました。
- [AI・機械学習の用語](https://kdot.co.jp/handbook/glossary/categories/ai-machine-learning): AI で何ができ、どこにリスクがあるか。導入の可否と進め方を判断するための語を集めました。
- [セキュリティ・運用の用語](https://kdot.co.jp/handbook/glossary/categories/security-operations): 安全に保ち、止めずに動かし続ける。事故を防ぎ、起きたときに被害を抑えるための語を集めました。
- [プロダクトマネジメント・組織の用語](https://kdot.co.jp/handbook/glossary/categories/product-management): 誰が何を決め、チームをどう動かすか。プロダクトの進め方と組織の設計に使う語を集めました。
- [アジャイル開発](https://kdot.co.jp/handbook/glossary/agile-development): 開発対象を最初にすべては確定させず、数週間ごとに動作するものを構築して確認し、優先順位を再検討しながら開発を継続する考え方です。発注側が継続して関与する手間がかかります。
- [暗号化](https://kdot.co.jp/handbook/glossary/encryption): データを鍵で変換し、鍵を保有する者だけが内容を復元できるようにする処理です。通信と保存データの区別、暗号化で防止できない被害、鍵の管理、漏えい時の報告との関係を解説します。
- [RFP](https://kdot.co.jp/handbook/glossary/rfp): 発注先を選定するために、求める要件と評価の観点を示して提案を求める文書です。仕様を確定する前の情報収集とは区別し、提案の前提を共通化するために使用します。
- [Infrastructure as Code](https://kdot.co.jp/handbook/glossary/infrastructure-as-code): サーバーやネットワークなどのインフラの構成を設定ファイルに記述し、その記述をもとに構築ツールが環境を構築・変更する進め方です。同じ構成を反復して構築でき、設定ファイルの版管理を併用すると、引き継ぎや監査の際に変更の履歴を追跡できます。
- [ERP](https://kdot.co.jp/handbook/glossary/erp): 会計、販売、購買、在庫などの基幹業務を1つのデータで連携する統合パッケージです。費用と期間は製品の標準に業務をどこまで適合させられるかで変わります。
- [ETL](https://kdot.co.jp/handbook/glossary/etl): データを抽出し、利用しやすい形に変換してから格納する処理です。分析に使う数字を揃えられますが、変換規則と更新の保守が必要です。
- [Webアプリケーション](https://kdot.co.jp/handbook/glossary/web-application): 利用者側の導入と更新の作業は少ない一方、サーバーの運用、ブラウザへの対応、権限確認が継続して必要になる、ブラウザで使う業務ソフトウェアです。
- [ウォーターフォール開発](https://kdot.co.jp/handbook/glossary/waterfall): 要件定義、設計、実装、テストの工程を順に1回ずつ実施し、前の工程を確定させてから次へ移行する開発の進め方です。何を開発するかを開始前に決め切れる案件向けで、途中の変更には追加の費用と期間がかかります。
- [受け入れテスト](https://kdot.co.jp/handbook/glossary/acceptance-testing): 完成したシステムを発注側の業務担当者が実際の業務の流れどおりに操作し、業務で利用できる状態かを確認するテストです。開発会社のテストでは発見できない業務との不一致を、稼働前に検出します。
- [請負契約と準委任契約](https://kdot.co.jp/handbook/glossary/fixed-price-contract): システム開発を外部へ委託するときの代表的な2つの契約形態です。請負は完成した成果物を、準委任は作業の遂行を支払いの対象とします。どちらを選択するかで、完成の責任、仕様変更の扱い、費用の上限が変化します。
- [運用・保守](https://kdot.co.jp/handbook/glossary/operations-and-maintenance): 稼働中のシステムを利用可能な状態を維持する運用と、不具合の修正や環境の変化への追従で品質を確保する保守です。開発と対になる工程で、基幹業務を委託する場合の費用は開発費の1〜2割程度が目安になります。
- [SLA](https://kdot.co.jp/handbook/glossary/sla): サービスの提供者と利用者の間で、稼働率や復旧時間などの水準を数値で規定する文書です。数字そのものより、算定方法と除外条件と補償の範囲が実質を左右します。
- [SOA](https://kdot.co.jp/handbook/glossary/soa): 業務の機能を他のシステムから呼び出し可能なサービスとして分離し、連携させて全社のシステムを構築する設計の考え方です。中央の連携製品に依存する構成は変更のたびに作業が中央に集中するため、現在は各システムが機能の呼び出し口を公開する形に引き継がれています。既存の連携基盤は変更にかかる期間と、変更に対応できる担当者がいるかで評価します。
- [MCP](https://kdot.co.jp/handbook/glossary/mcp): AIアプリケーションを社内外のシステムやデータに接続する方式を定めた公開の規格です。一度開発した接続を、MCPに対応した複数のAI製品から利用できますが、接続したAIに許可する操作と人の承認は、利用する組織が設計します。
- [MVP](https://kdot.co.jp/handbook/glossary/mvp): MVP（Minimum Viable Product）は、新規の製品やサービスが利用されるかを、作り込みの前に実際の利用者で検証する最初の版です。反応を観測する体制がない場合や、需要と使い方が確認済みの刷新は、対象外です。
- [LLM-as-a-Judge](https://kdot.co.jp/handbook/glossary/llm-as-a-judge): 別のLLMに採点の基準を提示し、LLMの出力を採点させる評価の方法です。担当者の採点に1日程度が必要な件数を短時間で採点できますが、判定に偏りがあるため、人の採点との一致を確認した項目にだけ利用します。
- [LLMの評価（eval）](https://kdot.co.jp/handbook/glossary/llm-evaluation): LLMを組み込んだシステムに用意した課題を入力し、出力を事前に定めた合格の基準で採点して、業務で利用できる品質かを測定する仕組みです。モデルやプロンプトを変更するたびに同じ課題で採点し、品質の改善と劣化を判定します。
- [AIエージェント](https://kdot.co.jp/handbook/glossary/ai-agent): 目標の達成のために自律的に行動するAIシステムです。業務ではAIが手順を自ら決定し、検索や社内システムを操作しながら複数の作業を処理する形で利用されます。例外の多い業務に適する一方、権限の範囲、人の確認、ログ、費用の上限を定めてから委任します。
- [AIガバナンス](https://kdot.co.jp/handbook/glossary/ai-governance): AIの利用で生じるリスクを許容できる水準に管理しながら、AIの便益を最大化するために、組織が方針、責任者、確認の手順を定めて運用する仕組みです。AIの誤りによる顧客や個人への影響が重大な用途ほど、管理を厚くします。
- [AIガードレール](https://kdot.co.jp/handbook/glossary/ai-guardrails): 生成AIへの入力とAIの出力、AIが実行する操作を、事前に定めた規則で自動判定し、規則に違反するものを遮断・修正する仕組みです。誤検知と見逃しは残存するため、権限の限定や人の承認と併用します。
- [AI推論](https://kdot.co.jp/handbook/glossary/ai-inference): 学習済みのAIモデルに新規のデータを入力して、予測値、分類の結果、文章などの出力を得る処理です。AIを業務で利用するたびに発生し、推論の実行場所と方式の選択で、利用料の形、応答の速度、データの処理場所が変化します。
- [AIベンチマーク](https://kdot.co.jp/handbook/glossary/ai-benchmark): AIモデルの性能を共通の課題と採点の手順で測定し、モデルどうしを比較するための試験です。候補のモデルの選別に有用ですが、自社の業務での品質は示さないため、採用は自社の課題による評価で決定します。
- [エージェンティックワークフロー](https://kdot.co.jp/handbook/glossary/agentic-workflow): 業務の流れの中にLLMが判断や文章の生成を担当する工程を組み込み、手順の一部をLLMに決定させる自動化の形態です。手順を固定するRPAやワークフローより例外に対応しやすい一方、判断のばらつき、費用の変動、評価の手間を管理する必要があります。
- [エージェントスキル](https://kdot.co.jp/handbook/glossary/agent-skills): AIエージェントに業務の手順、参考資料、プログラムをフォルダ単位で付与し、該当する作業のときだけ読み込ませる仕組みです。同じ指示を毎回記述する手間を削減できる一方、内容の改訂と、外部から入手したスキルの審査が必要です。
- [エージェントハーネス](https://kdot.co.jp/handbook/glossary/agent-harness): AIエージェントのうちモデル以外の部分で、ツールの実行、作業の記録、手順の反復と停止、権限と承認、結果の確認を担うソフトウェアです。同じモデルでもハーネスによって成果と費用が変化するため、エージェントはハーネスを含めた全体で評価します。
- [API](https://kdot.co.jp/handbook/glossary/api): あるシステムの機能やデータを別のシステムが所定の手順で呼び出して利用できるようにした窓口です。CSVの受け渡しで十分な場面も多く、APIは開発後も保守が継続します。
- [APIキー](https://kdot.co.jp/handbook/glossary/api-key): APIを呼び出すプログラムを識別するために、サービスが発行する文字列です。漏えいすると第三者に利用され、利用料の請求やデータの流出につながるおそれがあります。保管場所、権限の絞り込み、漏えい時の対処を解説します。
- [オンプレミス](https://kdot.co.jp/handbook/glossary/on-premises): サーバーやネットワークを自社の設備として保有し、自社の責任で運用する形態です。統制とデータの所在は自社で決定できますが、設備、電気、要員、更新の費用は継続して負担します。
- [OS](https://kdot.co.jp/handbook/glossary/os): OS（オペレーティングシステム）は、パソコンやサーバーの機器を管理し、その上で業務アプリケーションを稼働させる基本のソフトウェアです。サポート期限が業務システムの更新計画を左右する理由と、移行の判断を解説します。
- [仮想化](https://kdot.co.jp/handbook/glossary/virtualization): 1台の物理的なコンピューターの上に、ソフトウェアで複数のコンピューターの環境を構築する技術です。サーバーの台数と設備費を削減できる一方、仮想化の基盤そのものの更新、ライセンス、障害時の影響範囲の管理が新たに発生します。
- [監視](https://kdot.co.jp/handbook/glossary/monitoring): 稼働中のシステムの状態を継続して計測し、異常を検知したときに担当者へ通知する仕組みです。監視する範囲と、夜間や休日に誰が対応するかは、業務が停止してよい時間から決定します。
- [概算見積](https://kdot.co.jp/handbook/glossary/rough-estimate): 開発対象がまだ確定していない段階で、費用と期間の規模感を把握するために算出する見積もりです。構想段階では実際の費用が見積もりの4分の1から4倍までぶれうるため、金額は一点でなく幅で管理します。
- [機械学習](https://kdot.co.jp/handbook/glossary/machine-learning): データから規則性を学習させ、需要予測や異常検知、分類などをさせる技術です。予測用のモデルを構築するのは、集計やルールによる予測からの改善分の価値が、データの整備と運用中の監視・再学習にかかる費用を上回るときです。
- [基幹システム](https://kdot.co.jp/handbook/glossary/core-system): 販売、購買、在庫、生産、会計、人事給与など、取引を金額と数量で確定させて記録する業務のシステムです。基幹システムには変化の少ない処理だけを実装し、変更頻度の高い機能は周辺のシステムで開発するほうがよいです。
- [技術的負債](https://kdot.co.jp/handbook/glossary/technical-debt): ソフトウェアの作りに改善の余地があり、以後の変更に余分な手間がかかる状態を借金にたとえた言葉です。開発の速度を優先して意図して負うことも、知識不足や運用後の発見で生じることもあります。
- [クラウド](https://kdot.co.jp/handbook/glossary/cloud-computing): クラウドは必要なときに必要な分だけ事業者の設備を通信回線ごしに利用する形態です。一般にはパブリッククラウドを指します。初期費用は抑制できますが、通信量で請求額が変化し、外貨建ての契約では為替でも変化します。終了時には移行の費用がかかります。
- [検収](https://kdot.co.jp/handbook/glossary/acceptance-inspection): 納品されたシステムや成果物を発注側が確認し、契約どおりと認めて受領する手続きです。支払い、権利の移転、不具合を無償で修正してもらえる期間の起点は、多くの契約で検収を境に確定します。
- [KPI](https://kdot.co.jp/handbook/glossary/kpi): 目標に対する進捗や達成度を、数値で定期的に確認する指標です。測定しやすい数字ではなく、自分たちの行動で変動させられ、目標の達成度を左右する数字を少数に限定し、確認した後の行動まで決定することで機能します。
- [構造化出力](https://kdot.co.jp/handbook/glossary/structured-output): LLMの出力を、事前に定めた項目と型の形式に従わせる機能です。システムが出力をそのまま処理できるようになりますが、形式が正確でも内容の正確さは保証されないため、値の確認は別に実施します。
- [コンテキストウィンドウ](https://kdot.co.jp/handbook/glossary/context-window): LLMが1回の処理で参照できる文章の量の上限で、トークンの数で表示します。指示、資料、会話履歴、ツールの結果がこの上限を共有し、主要なモデルでは回答も上限に含まれます。上限の範囲内でも入力が長いほど精度が低下することがあります。
- [コンテキストエンジニアリング](https://kdot.co.jp/handbook/glossary/context-engineering): LLMが回答や作業の各段階で参照する指示、資料、会話の履歴、ツールの結果を選択し、整理して入力する設計の取り組みです。情報は多いほど良いわけではないため、必要な情報を必要な時点で入力します。
- [コンテナ](https://kdot.co.jp/handbook/glossary/container): アプリケーションと稼働に必要なソフトウェア一式を1つに集約し、開発から本番まで同じ中身で稼働させる仕組みです。新規のWebシステムでは有力な選択肢ですが、中身を更新し続ける保守の作業は引き続き発生します。
- [コーディングエージェント](https://kdot.co.jp/handbook/glossary/coding-agent): コーディングエージェントは、結果を確認しながら、ソースコードの読み取りと書き込みから、コマンドとテストの実行までを自律的に反復するAIです。人が1手ずつ実行しなくても作業が進むため、委任する範囲、レビュー、権限、機密情報の扱いを先に決定します。
- [再委託](https://kdot.co.jp/handbook/glossary/subcontracting): 発注先の会社が受注した業務の一部をさらに別の会社へ委託することです。再委託が反復すると多重下請けの状態になり、情報管理、品質、費用、責任の所在を発注側から把握しにくくなります。
- [サイバー攻撃](https://kdot.co.jp/handbook/glossary/cyber-attack): インターネットや社内ネットワークを通じて、組織のシステムやデータを停止、改ざん、窃取しようとする行為の総称です。主な手口、侵入から被害までの流れ、被害の規模、備えの順番を解説します。
- [サプライチェーン攻撃](https://kdot.co.jp/handbook/glossary/supply-chain-attack): 取引先や利用しているソフトウェアの脆弱な箇所を経由して、標的の組織を間接的に攻撃する手口です。
- [SaaS](https://kdot.co.jp/handbook/glossary/saas): 事業者が運用するソフトウェアを、インターネット経由でサービスとして利用する形態です。調達と保守は事業者側に移行する一方、業務を製品の標準に適合させる判断と、利用者と権限の管理は自社が担います。
- [サーバー](https://kdot.co.jp/handbook/glossary/server): 社内外の利用者に機能やデータを提供するコンピューターです。物理サーバー、役割、仮想サーバーの違いと、台数や構成によって費用、停止したときの影響、運用の負担が変わる理由を解説します。
- [サーバーレス](https://kdot.co.jp/handbook/glossary/serverless): サーバーの準備や管理をクラウド事業者に任せる実行方式です。処理量の変化に対応しやすい一方、料金や実行時間の制限はサービスごとに確認が必要です。
- [システム移管](https://kdot.co.jp/handbook/glossary/system-handover): 稼働中のシステムの運用・保守・改修の担当と責任を、別の組織や担当者へ引き継ぐことです。資料の引き渡しだけでは完了せず、新担当が自力で運用できると確認するまでが範囲です。
- [シングルサインオン](https://kdot.co.jp/handbook/glossary/single-sign-on): 一度の本人確認を利用して複数のサービスにログインする仕組みです。認証と権限管理の違い、退職時の停止、共通アカウントの不正利用や障害への備えを解説します。
- [CI/CD](https://kdot.co.jp/handbook/glossary/ci-cd): ソースコードの変更をこまめに統合し、自動でテストして、いつでも本番に反映できる状態を維持する開発の進め方とその仕組みです。リリースが迅速になるほか不具合を混入させたときに前のバージョンへ切り戻しやすくなります。
- [CDP](https://kdot.co.jp/handbook/glossary/cdp): 複数の接点にある顧客データを同じ人ごとに統合し、他のシステムが利用できる形で保持するソフトウェアです。既存のCRMやデータウェアハウスで十分な場合もあります。
- [情報セキュリティ](https://kdot.co.jp/handbook/glossary/information-security): 情報を、許可された人だけが、正しい内容のまま、必要なときに使える状態に保つことです。機密性・完全性・可用性の3要素、保護の強さの決め方、運用の負担を解説します。
- [推論モデル](https://kdot.co.jp/handbook/glossary/reasoning-model): 回答の前に内部で思考の過程を生成し、問題を分解して解き方を検討してから回答するLLMです。複雑な計算、コード、多段の計画で正確さが向上することが多い一方、待ち時間と費用が増加するため、作業の種類ごとに思考の量を決定して利用します。
- [スクラッチ開発](https://kdot.co.jp/handbook/glossary/scratch-development): 既製のパッケージやSaaSを基盤にせず、自社の業務を前提にシステムを設計から開発する形です。業務が競争力の源泉で、既製品では差を解消できないときに採用し、保守の費用と人材まで含めて採否を決定します。
- [スクラム](https://kdot.co.jp/handbook/glossary/scrum): 1か月以内の短い期間ごとに動作するものを構築し、その結果をもとに次の計画を再検討するチーム開発の枠組みです。発注側からプロダクトオーナーを選出し、毎回の優先順位を決定し続ける負荷を計画に含める必要があります。
- [スコープクリープ](https://kdot.co.jp/handbook/glossary/scope-creep): 当初合意した作業範囲が明示的な判断のないまま少しずつ拡大する状態です。変更の件数ではなく、費用と納期への影響を確認しないまま追加が積み上がる点が問題になります。
- [生成AI](https://kdot.co.jp/handbook/glossary/generative-ai): 指示に応じて文章や画像、プログラムを生成するAIです。下書きや要約の時間を削減できる一方、出力は確率的で正確性は保証されず、確認工程と入力制限の設計が導入の条件になります。
- [セキュリティパッチ](https://kdot.co.jp/handbook/glossary/security-patch): ソフトウェアの提供元が、見つかった脆弱性を修正するために配布する更新プログラムです。適用の速さの決め方、停止と検証の負担、誰が適用するかの分担を解説します。
- [セマンティックレイヤー](https://kdot.co.jp/handbook/glossary/semantic-layer): 指標の計算方法と意味を1か所に定義し、BIツールや表計算、AIが同じ定義を参照できるようにする層です。部署間の数字のずれを軽減しますが、定義の保守と変更管理の担当が必要です。
- [脆弱性](https://kdot.co.jp/handbook/glossary/vulnerability): 脆弱性はソフトウェアや設定に含まれるセキュリティ上の弱点です。あるだけでは被害にならず、悪用の条件が成立すると被害に発展します。放置の影響、対処の優先順位、更新の運用負担を解説します。
- [脆弱性診断](https://kdot.co.jp/handbook/glossary/vulnerability-assessment): システムに疑似的な攻撃の通信を送るなどして、決めた範囲から攻撃のきっかけになる弱点を洗い出す作業です。対象と時期と方法の決め方、費用、本番環境への影響を解説します。
- [ゼロデイ攻撃](https://kdot.co.jp/handbook/glossary/zero-day): 修正パッチの提供前に脆弱性を悪用する攻撃です。パッチがない期間に組織が行う緩和、露出の削減、検知と、パッチ公開後の侵害調査を解説します。
- [ゼロトラスト](https://kdot.co.jp/handbook/glossary/zero-trust): 社内ネットワークや会社の端末という理由だけで信頼せず、情報やアプリごとに利用者や端末を確認し、必要なアクセスを許可する考え方です。
- [多要素認証](https://kdot.co.jp/handbook/glossary/multi-factor-authentication): 性質の異なる複数の要素を併用して本人を確認する仕組みです。コード入力とパスキーの違い、どのアカウントから設定するか、端末紛失時の復旧方法を解説します。
- [大規模言語モデル](https://kdot.co.jp/handbook/glossary/llm): 大量の文章から語の並びの傾向を学習し、指示に応じて文章を生成するモデルです。システムから呼び出すAPIでは主に処理した文章量で課金され、処理できる量と知識の時点に上限があるため、自社の業務の実例で比較して選定します。
- [ツール呼び出し](https://kdot.co.jp/handbook/glossary/tool-use): LLMがデータの検索やシステムへの登録といった登録済みの機能から利用するものを選択し、実行の内容を指示する仕組みです。LLMに何を実行させるかは、登録する機能と、実行するアプリケーションや接続先のシステムの権限で決定されます。
- [DX](https://kdot.co.jp/handbook/glossary/dx): データとデジタル技術を活用して、製品やサービス、ビジネスモデル、業務や組織を変革し、競争上の優位性を確立することです。ツールの導入や紙の電子化は手段で、それだけでは該当しません。
- [データ移行](https://kdot.co.jp/handbook/glossary/data-migration): 旧システムのデータを新システムで利用できる形式に変換して移行する工程です。抽出、変換、投入、突合の4段で進行し、工数は件数より項目の対応関係と例外の数で確定します。
- [データウェアハウス](https://kdot.co.jp/handbook/glossary/data-warehouse): 業務システムなどのデータを収集し、過去分を含めて集計可能な形で蓄積する分析用のデータベースです。基幹システムの集計表とExcelで履歴の保持・処理速度・管理の要件を充足できているなら、早期に導入する必要はありません。
- [データガバナンス](https://kdot.co.jp/handbook/glossary/data-governance): 社内のデータの意味、管理の責任者、品質、利用の可否、保管期間を決定する権限と、その遵守を確認する手順を定める仕組みです。全社一斉の規程より、数字が一致しない指標や個人情報など対象を限定して開始します。
- [データ基盤](https://kdot.co.jp/handbook/glossary/data-platform): データ基盤は定義を1か所に統合し、集計の重複を削減する仕組みです。数字が一致するかは定義次第です。定義を決定するのは業務部門です。
- [データベース](https://kdot.co.jp/handbook/glossary/database): 業務データを整理して保存し、複数の人やシステムが同時に正確に読み書きできるようにする仕組みです。共有の表計算ファイルから移す目安、種類の選び方、導入後の運用負担を解説します。
- [データレイク](https://kdot.co.jp/handbook/glossary/data-lake): 業務データ、ログ、画像、文書など形式の異なるデータを、元の形式を含めて一括で保管し、分析や機械学習に利用する基盤です。出どころと管理者を記録せずに蓄積すると、必要なデータを検索できず、利用の可否も決定できない置き場になりやすくなります。
- [トークン（生成AI）](https://kdot.co.jp/handbook/glossary/llm-token): LLMが文章を処理するときの単位で、文字、語の一部、語、記号のいずれにもなります。APIの料金とコンテキストウィンドウの上限はトークンの数で規定され、レート制限もトークンの数とリクエスト数で設定されます。費用は、使用するモデルで自社の文章のトークン数を計測して見積もります。
- [内製化](https://kdot.co.jp/handbook/glossary/insourcing): システムの企画・開発・運用を、外部へ任せきりにせず自社の組織で担うことです。全部を自社で開発することではなく、競争力と関係する領域に限定し、決定する人と改修できる人を社内へ配置するのが現実的です。
- [人月](https://kdot.co.jp/handbook/glossary/person-month): 1人が1か月働く作業量の単位です。システム開発の見積もりの算出基礎として利用され、準委任では支払いの単位にもなります。人と月は交換できず、担当者による生産性の差も反映しません。
- [認証情報](https://kdot.co.jp/handbook/glossary/credentials): システムやサービスに本人や正規のプログラムとして接続するための情報の総称です。人のものとプログラムのものの違い、優先して守るアカウント、漏えいしたときの対処を解説します。
- [ハルシネーション](https://kdot.co.jp/handbook/glossary/hallucination): 生成AIが事実と異なる内容や存在しない出典を、もっともらしく生成する現象です。誤りがないことは保証できないため、誤りの影響と発見のしやすさに応じて確認の重さを決定します。
- [ハーネスエンジニアリング](https://kdot.co.jp/handbook/glossary/harness-engineering): AIエージェントに作業を委任できるよう、作業ルール、ツール、テスト、承認の仕組みといったモデルの外側を設計し、改修し続ける取り組みです。機械で結果を判定できるようにした範囲で、委任する作業を拡大します。
- [バイブコーディング](https://kdot.co.jp/handbook/glossary/vibe-coding): 生成AIに自然言語で指示し、出力されたコードを精査せずに採用して動作するものを作成する開発の仕方です。誰もコードを理解していないため、使い捨ての試作には有効ですが、顧客データを処理する本番や長期の保守では不具合の検知と改修が困難になります。
- [バックアップ](https://kdot.co.jp/handbook/glossary/backup): 障害、誤操作、攻撃でデータが消失したときに復元できるよう、データを別の場所に複製して保管することです。ランサムウェアの被害ではバックアップを取得していてもデータを復元できない事例が多く、業務ごとに復元したい時点と停止できる時間から方式を決定します。
- [パッケージ開発](https://kdot.co.jp/handbook/glossary/package-development): 既製の業務パッケージを導入し、設定、カスタマイズ、アドオンで自社の業務に適合させるシステム開発の形です。費用と保守の負担は作り込みの量に応じて増加します。
- [パブリッククラウド](https://kdot.co.jp/handbook/glossary/public-cloud): パブリッククラウドは、事業者が一般の利用者に向けて提供するクラウドです。利用者は自社で設備を用意せず、必要な分を契約して使います。障害時に影響が及ぶ範囲と専有の要件は、利用するサービスと構成によって異なります。
- [PaaS と IaaS](https://kdot.co.jp/handbook/glossary/paas-iaas): クラウドの利用形態の分類です。IaaSは仮想サーバーなどの基盤を利用してOSから上を自社で管理し、PaaSはOSと実行環境まで事業者が管理し、自社はアプリケーションを用意します。
- [非機能要件](https://kdot.co.jp/handbook/glossary/non-functional-requirements): システムに求める条件のうち、停止しにくさ、速度、安全さ、保守のしやすさなど機能以外の水準を定めたものです。水準を向上させるほど費用が大幅に増加するため、業務への影響から必要な分だけを定めます。
- [ヒューマンインザループ](https://kdot.co.jp/handbook/glossary/human-in-the-loop): AIの処理の途中に人の確認や承認を組み込み、人が承認するまで処理を停止する設計です。すべての操作に承認を求めると確認が形骸化するおそれがあるため、取り消し不能な操作や社外に影響する操作の直前に限定して配置します。
- [BI](https://kdot.co.jp/handbook/glossary/bi): 事業に関するデータを集計・分析し、意思決定に活用する取り組みです。BIツールは集計や可視化を支援しますが、指標の定義と更新の管理も必要です。
- [PoC](https://kdot.co.jp/handbook/glossary/poc): 新規の技術や仕組みが自社の業務とデータで狙いどおりに機能するかを、本格的な開発の前に小規模な仕組みで検証する取り組みです。開始する前に、何が分かれば次の段階へ移行し、何なら中止するかを定めておきます。
- [ファインチューニング](https://kdot.co.jp/handbook/glossary/fine-tuning): 学習済みのAIモデルを追加の学習で特定の作業に適合させる方法です。分類や書式、口調のばらつきを低減できる場合があります。プロンプトの工夫では出力が安定せず、学習データと評価を維持できる作業に採用し、維持できない作業には採用しません。
- [フィッシング](https://kdot.co.jp/handbook/glossary/phishing): 実在する企業やサービスを詐称し、情報の入力や不正な操作へ誘導する攻撃です。情報入力・認証の承認・アプリへの権限許可など、実施した操作に応じた対処と認証方式の選び方を解説します。
- [VPN](https://kdot.co.jp/handbook/glossary/vpn): インターネットなどの既存の通信網を利用し、限られた相手との接続を確立する技術です。端末と拠点間の接続、保護される通信範囲、SaaSでの必要性とアクセス管理を解説します。
- [プライベートクラウド](https://kdot.co.jp/handbook/glossary/private-cloud): プライベートクラウドは1つの組織だけが専用で利用するクラウド環境です。仮想化して集約しただけの基盤とは、利用者の申請による自動の用意と利用量の計測の有無で区別します。設備は自社の施設にも事業者のデータセンターにも設置できます。
- [プロダクトマネージャー](https://kdot.co.jp/handbook/glossary/product-manager): 自社の製品やサービスについて、何を開発するか、事業として成立するかを判断し、成果に責任を負う役割です。肩書きより判断の権限と時間の有無が役割の機能を左右し、小さな製品では事業責任者が兼任して開始できます。
- [プロンプトインジェクション](https://kdot.co.jp/handbook/glossary/prompt-injection): AIが処理する文章や画像に混入させた指示で、本来の指示や制限を無視させる攻撃です。プロンプトの工夫や入力の選別だけで確実に防止できるとは限らず、権限と外部への送信手段をシステム側で限定し、重要な操作の前に人が確認する設計で被害を軽減します。
- [プロンプトエンジニアリング](https://kdot.co.jp/handbook/glossary/prompt-engineering): 生成AIの出力を安定させるために、プロンプトに記述する指示、例、出力の形式を設計し、評価しながら改善する取り組みです。モデルを変更せずに試行できる最初の手段で、改善の効果は自社の実例で測定します。
- [並行稼働](https://kdot.co.jp/handbook/glossary/parallel-operation): 新旧のシステムを一定期間同時に稼働させ、同じ業務を両方で処理して結果を比較する切替の対策です。対象と期間を限定しないと現場の負担と費用が増大します。
- [ベンダーロックイン](https://kdot.co.jp/handbook/glossary/vendor-lock-in): 特定の開発会社や製品、クラウドへの依存が過度になり、他社への移行が費用の面で困難になった状態です。ゼロにはできないため、どこまで許容し、どこを契約と設計で回避するかを決定します。
- [ペネトレーションテスト](https://kdot.co.jp/handbook/glossary/penetration-testing): 攻撃者と同じ手法でシステムへの侵入を試み、攻撃の目的を達成できるかを確認する試験です。脆弱性診断との違いと、実施の時期、事前の承諾を解説します。
- [マイクロサービス](https://kdot.co.jp/handbook/glossary/microservices): 1つのシステムを機能ごとに独立して開発・リリースできる小さなサービスの集まりとして構築する設計の考え方です。機能ごとに独立してリリースする必要がない会社では不要で、まず1つのシステムで構築するほうがよいです。
- [マネージドサービス](https://kdot.co.jp/handbook/glossary/managed-service): データベースなど特定の機能を、OSやソフトウェアの更新、バックアップの取得まで含めてクラウド事業者が運用するサービスです。設定の自由度は事業者の範囲に限られ、障害時の構成の選択と権限の管理は利用者が担います。
- [マルチエージェント](https://kdot.co.jp/handbook/glossary/multi-agent): 複数のAIエージェントに作業を分担させ、結果を統合して1つの目的を達成する構成です。独立した調査を並行できる作業では成果と速度が向上することがある一方、費用が増加し分担の誤りも発生するため、1つのエージェントで不足する作業に限って採用します。
- [マルチクラウド](https://kdot.co.jp/handbook/glossary/multi-cloud): 複数の事業者のパブリッククラウドを併用する形態です。システムごとに別の事業者を選択する併用は問題になりにくい一方、1つのシステムを複数のクラウドに分散して構成すると、費用と運用の負担が増加する傾向にあります。
- [モノリス](https://kdot.co.jp/handbook/glossary/monolith): 全機能を1つのプログラムに集約し、一括で稼働・リリースする作り方です。多くの会社にとって標準の選択肢で、中を業務単位で分割した状態を維持すれば長く使い続けられます。
- [ユーザーストーリー](https://kdot.co.jp/handbook/glossary/user-story): システムにしてほしいことを、利用者の目的とともに短く整理した計画の単位です。詳細は開発開始が接近するにつれて会話で具体化するため、全体の範囲は別に決定し、遵守すべき条件も別に用意する必要があります。
- [要件定義](https://kdot.co.jp/handbook/glossary/requirements-definition): 新システムで何をどこまで実現するかを、開発の前に決定して文書化する工程です。決定する責任は発注側にあり、範囲が確定していないなら要件定義だけを先に別契約で締結するほうが、見積もりの前提が発注側と開発会社で一致しない事態を防止しやすいです。
- [RAG](https://kdot.co.jp/handbook/glossary/rag): 質問に関係する資料を検索で抽出し、その内容とともに生成AIへ入力して回答を作成させる仕組みです。回答の精度は資料の整備、検索の質、モデルやプロンプトの設計に左右され、資料の更新と権限の管理が継続的に必要です。
- [ランサムウェア](https://kdot.co.jp/handbook/glossary/ransomware): 端末やデータを利用できなくし、利用の回復と引き換えに対価を要求する不正プログラムです。事業停止や情報窃取の影響、感染の可能性があるときの初動、バックアップと復旧の備えを解説します。
- [リバースエンジニアリング](https://kdot.co.jp/handbook/glossary/reverse-engineering): 完成したソフトウェアや製品を解析して、仕組みや仕様を把握する手法です。実施前に権利・契約と調査範囲を確認し、結果は実際の挙動と比較して検証する必要があります。
- [レガシーシステム](https://kdot.co.jp/handbook/glossary/legacy-system): 変更が困難になり、中身を分かる人も限られて、事業の足かせになったシステムです。保守費の膨張や、稼働させている基盤のサポート終了を伴うことが多いです。
- [ローコード・ノーコード](https://kdot.co.jp/handbook/glossary/low-code): プログラムをほとんど記述せずに、画面の構成要素や設定で業務アプリを開発する手法と開発基盤です。現場の社員が自ら開発する使い方と、開発会社が生産性を向上させるために利用する使い方があります。

## ハンドブック

- [ハンドブック](https://kdot.co.jp/handbook): システム開発や業務の仕組みづくりで直面する課題を解決するための、方法論と知識をまとめています。
- [開発を頼む・進める](https://kdot.co.jp/handbook/topics/system-development)
- [なぜテストのないシステムは言語やライブラリの更新が先送りされ続けるのか](https://kdot.co.jp/handbook/update-postponed-without-tests): 回帰テストとステージング環境が無いと更新のたびに人の確認の費用と停止の危険が生じ、一度先送りした更新は再び後回しになりやすくなります。サポート終了後に脆弱性が公開されると、何年分もの更新を短期間で実施するか遮断や停止を選択します。
- [生成AIが広まってからセキュリティ事故が増えているのはなぜか](https://kdot.co.jp/handbook/llm-security-incidents): 攻撃の手口は以前と同じで、変化したのは攻撃の数と速さです。生成AIが攻撃1件の費用を低下させ、試行の回数に比例して成功する詐欺と脆弱性の悪用が増加しました。ランサムウェアの被害件数は横ばいです。
- [見積が会社によって何倍も違う。どれが妥当で、どう比べればよいか](https://kdot.co.jp/handbook/estimate-comparison): 見積の金額は、各社が依頼文から想定した開発範囲の値段です。会社ごとの金額の何倍もの差は想定した開発範囲の差なので、依頼の前に要件を整理し、前提を統一してから内訳で比較します。
- [開発会社を変更したい。システムの移管は可能か、最初に何を確認すればよいか](https://kdot.co.jp/handbook/vendor-handover): 移管できます。継続改修か再構築かは、自社に何があるかによって変わります。最初に権利と名義と稼働方法を確認します。

## KDOT Engineering

- [KDOT Engineering](https://kdot.co.jp/kdotdev/pages/1): エンジニアリングブログのトップ
- [技術スタック](https://kdot.co.jp/kdotdev/technology-stack): 利用技術のカタログ
- [テーマ一覧](https://kdot.co.jp/kdotdev/tag): 記事タグ（テーマ）一覧
- [tsc v7対応記録](https://kdot.co.jp/kdotdev/typescript-7-migration-record): TypeScript 7への移行での型定義・tsconfig・周辺ツールの変更を、複数パッケージ構成の実例で記録する。7系と6系APIの共存、peer範囲の修正方法、削除された設定の代替まで対象とする。移行の判断材料も提示する。
- [Next.js上のPayload CMSでリアルタイムpreviewを組み立てる](https://kdot.co.jp/kdotdev/payload-cms-live-preview): Payload CMSのlive previewを、編集画面とフロントの2要素で最小構成にする。iframe越しにCookieが消える原因と、SameSite=NoneとURL secretの選定方法を整理する。
- [Storybookで画面操作説明の画像をAI Agentに作らせる](https://kdot.co.jp/kdotdev/storybook-ai-agent-screenshot): 画面操作の説明画像をStorybookのstoryとして管理し、AI Agentに更新させる構成を解説する。番号バッジの位置をDOMから計測するdecoratorと、バイナリを差分管理しない手順を提示する。
- [rayonとtokioの使い分け](https://kdot.co.jp/kdotdev/rayon-tokio-choose): rayonとtokioを、速度ではなく仕事の性質で選択するための判断基準を整理する。CPU-boundのデータ並列とI/O-boundのタスク並行を分類し、混在処理にはspawn_blockingを適用する。
- [Payload CMSをCloudflare Workers/D1/R2で動かす](https://kdot.co.jp/kdotdev/payload-cms-cloudflare-stack-components): Payload CMSをCloudflareのWorkers・D1・R2・Accessに配分して稼働させる構成を、OpenNextのビルドから料金・性能の見方まで解説する。SSGと管理画面の管理も整理する。
- [Metabaseの権限モデル入門](https://kdot.co.jp/kdotdev/metabase-permission-model): Metabaseの権限設計を、データ・意味定義・保存済み分析・collectionの4層と、data/collectionの2軸で整理する。閲覧者と分析者を分類する設定手順とOSS/Proの差も対象とする。運用の注意点も提示する。
- [dylintでRustの自前lintを運用する](https://kdot.co.jp/kdotdev/dylint-custom-rust-lints): Clippyでは表せない組織固有のRust規約を、dylintのlint crateとして運用する手順を整理する。workspace metadata、ui_test、nightly固定、CIへの組み込みまでを対象とする。
- [RustでMarkdownをパースする — parserの選び方](https://kdot.co.jp/kdotdev/rust-markdown-parser-comparison): RustのMarkdown parser 4 crateを、API形状・位置モデル・GFM対応で同一原稿により比較する。linterや抽出ツールの用途別に、どのcrateをparse層へ配置するかを選択できるようにする。
- [Rustで日本語lintのために使用できる技術](https://kdot.co.jp/kdotdev/japanese-markdown-lint-architecture): 日本語Markdownをlintする4つの課題は、原文保持・語の分割・位置復元・結果連携である。各層の入出力からpulldown-cmarkやlinderaを選択する設計を解説する。
- [rowanでロスレス構文木を作る — 原文を捨てない構文表現と使い方](https://kdot.co.jp/kdotdev/rowan-lossless-syntax-tree): rowanのロスレス構文木を、green/redの二層構造からGreenNodeBuilder、走査、型付きビューまで、Markdownを題材にした実装例で解説する。原文位置を失わない設計を対象とする。
- [Pyrightの静的型付け：上級者向け解説](https://kdot.co.jp/kdotdev/type-concepts-advanced): Pyrightのtype narrowingを、条件分岐や型ガードで型を絞り込む仕組みから解説する翻訳記事。Union型の管理、isinstanceの効果、絞り込みされない記述方法を整理する。型の安全性を向上させる。
- [型推論についての理解](https://kdot.co.jp/kdotdev/type-inference): Pythonの型推論がシンボルとスコープ、型宣言、代入の流れからどう決まるかを解説する翻訳記事。型チェッカーが式の型を特定する手順と、推論されない状況を整理する。型注釈をどこまで記述するかの判断に活用できる。
- [Pylance: VS Codeにおいて最も優れたPython拡張機能](https://kdot.co.jp/kdotdev/pylance-the-best-python-extension-for-vs-code): PylanceとはVS CodeでPythonの型チェックと補完を担う言語サーバー。Microsoft公式の拡張機能として、型ヒントに基づく補完・診断・リファクタリングがどこまで対応できるかを解説する。導入の判断に活用できる。
- [Rust Webフレームワーク比較 Actix Web / Axum / Rocket / Poem](https://kdot.co.jp/kdotdev/rust-web-framework-comparison): RustのWebフレームワーク7つを、コード例とともに比較する翻訳記事。Actix Web・Axum・Rocket・Poemなどの特徴、学習コスト、採用時の判断基準を整理する。小さなAPIを構築する前提で比較する。
- [Hypothesis: 適切なデータの生成](https://kdot.co.jp/kdotdev/generating-the-right-data): 複雑なデータモデルに合致するテストデータを、Hypothesisで生成する方法を解説する翻訳記事。制約を戦略として表現し、現実的なデータを再現する例を整理する。
- [ForeignKeyを正しく設定しているのにsqlalchemy.exc.NoReferencedTableErrorが出る](https://kdot.co.jp/kdotdev/foreignkey-sqlalchemy-exc-noreferencedtableerror): ForeignKeyを正確に設定しているのにNoReferencedTableErrorが出る原因を、宣言的スタイルの解決順から解説する。relationshipの定義位置とimportの組み方で修正する方法を提示する。
- [SQLAlchemyでMany to Manyのモデルを分割する](https://kdot.co.jp/kdotdev/sqlalchemy-orm-many-to-many-relationship): SQLAlchemyの宣言的モデルでMany to Manyのrelationshipを持つ場合、モデルファイルを複数に分割すると型エラーや実行時エラーが発生する。循環参照を回避する定義順と型注釈の記述方法を解説する。
- [PythonのCallableで関数に型を付ける](https://kdot.co.jp/kdotdev/python-callable): PythonのCallableとは、関数の引数と戻り値の型を表すための仕組み。Callable[[int], str]のように記述し、コールバックや高階関数への型付与と、実行時には確認されない限界を解説する。
- [Hypothesisを用いたテスト最適化の探求](https://kdot.co.jp/kdotdev/testing-optimizers-with-hypothesis): ナップサック問題を例に、Hypothesisで最適化アルゴリズムをテストする方法を解説する翻訳記事。出力の性質をプロパティとして記述し、探索の妥当性を検証する手順を提示する。
- [テストパフォーマンスの最適化](https://kdot.co.jp/kdotdev/testing-performance-optimizations): Hypothesisでパフォーマンス最適化をテストする方法を論じる翻訳記事。最適化の前後で性質が維持されるかを確認するテスト設計と、計測の注意点を整理する。
- [合成に基づいた縮小処理](https://kdot.co.jp/kdotdev/compositional-shrinking): 型に依存しない値の縮小を、合成の考え方で構成する方法を論じる翻訳記事。theftやQuickTheoriesを例に、ライブラリごとの縮小戦略の違いを整理する。
- [Hypothesisについて（研究者向け）](https://kdot.co.jp/kdotdev/hypothesis-for-researchers): 研究者向けに、Hypothesisがなぜ研究対象として有用かを解説する翻訳記事。プロパティベースドテストの理論的背景、実験の再現性、研究テーマとしての可能性を整理する。
- [Hypothesisの仕組み](https://kdot.co.jp/kdotdev/how-hypothesis-works): Hypothesisがテストケースを生成・保存・縮小する仕組みを、内部アーキテクチャから解説する翻訳記事。従来のテストフレームワークとの違いと、失敗例の再利用の考え方を整理する。
- [統合された縮小処理](https://kdot.co.jp/kdotdev/integrated-shrinking): HypothesisとQuickCheckの縮小処理の違いを、統合されたshrinkingの設計から解説する翻訳記事。失敗例を小規模化する仕組みが、テストの再現性とデバッグ体験にどう作用するかを提示する。
- [段階的なプロパティベースドテスト](https://kdot.co.jp/kdotdev/incremental-property-based-testing): 既存のPythonユニットテストから、段階的にプロパティベースドテストへ移行する手順を紹介する翻訳記事。最初に置き換えるテストの選定方法と、生成戦略を増加させる順序を整理する。
- [完全な仕様に基づいたテスト](https://kdot.co.jp/kdotdev/tests-as-complete-specifications): 問題の性質を完全に定義するテストを、Hypothesisで記述する方法を解説する翻訳記事。バイナリサーチを例に、仕様をプロパティとして表現し、実装の正確性を検証する考え方を提示する。
- [CloudflareはVercelの代替なりうるのか](https://kdot.co.jp/kdotdev/cloudflare-vs-vercel): CloudflareはVercelの代替になるのかを、previewデプロイ・Image Optimization・ISR・料金の4点で比較する。ISRと画像最適化の互換性を軸に、移行の判断材料を整理する。
- [閾値問題に関する考察](https://kdot.co.jp/kdotdev/threshold-problem): テストで小さなエラーを検出するときの閾値問題を、Hypothesisが最小の失敗ケースを特定する仕組みから解説する翻訳記事。しきい値付近の管理と、テスト設計に落とす際の判断を整理する。
- [sopsの使い方](https://kdot.co.jp/kdotdev/how-to-use-sops): sopsとは環境変数ファイルなどの秘密情報を暗号化したままGitで管理するためのCLI。AWS KMSを例に、暗号化・復号・チーム運用の手順と、鍵の管理で注意する点を解説する。CIでの復号と鍵のローテーションも対象とする。
- [マルチバグ発見](https://kdot.co.jp/kdotdev/multi-bug-discovery): Hypothesisが複数のバグを発見し、それぞれを単純化・管理する仕組みを解説する翻訳記事。失敗例の保存と再現、バグ同士が干渉するときの扱いを整理する。
- [型とプロパティ](https://kdot.co.jp/kdotdev/types-and-properties): プロパティベースドテストで、型システムとデータ生成をどう組み合わせるかを論じる翻訳記事。型から値を生成する利点と、Pythonのジェネレーターを利用する場合の考え方を整理する。
- [Hypothesisから学ぶ「ダイ・ハード」で生き残る方法](https://kdot.co.jp/kdotdev/how-not-to-die-hard-with-hypothesis): Hypothesisで「ダイ・ハード3」の水差し問題を解く過程から、プロパティベースドテストの探索と縮小の動きを解説する翻訳記事。制約のある問題をどうモデル化するかを提示する。
- [Pyright(Pylance)のtype check ruleの設定全部解説する: その2](https://kdot.co.jp/kdotdev/pyright-pylance-type-check-rule-2): Pyright（Pylance）のtype check ruleの後編。レポート対象のルールを初期化・未使用変数・例外処理などの分類ごとに解説し、有効化の判断と副作用を整理する。
- [Pyright(Pylance)のtype check ruleの設定全部解説する: その１](https://kdot.co.jp/kdotdev/pyright-pylance-type-check-rule): Pyright（Pylance）のtype check ruleを、設定項目ごとに解説する前編。strictモードの各診断ルールの対象と、なぜデフォルトで無効なのかを整理する。
- [ソフトウェアの正確性にまつわる経済学](https://kdot.co.jp/kdotdev/economics-of-software-correctness): ソフトウェアの正確性をどこまで向上させるかの経済学を、完全な正確性のコストとユーザー協力の限界から論じる翻訳記事。品質投資の判断基準を整理する。
- [ルールベースドステートフルテスティング](https://kdot.co.jp/kdotdev/rule-based-stateful-testing): ルールベースドステートフルテスティングを、状態を保持するシステムのテスト手法として解説する翻訳記事。状態機械とルールを定義し、遷移の組み合わせを自動で試行する考え方を提示する。
- [OpenAPIからフォームのバリデーションまでの型とコードを生成する](https://kdot.co.jp/kdotdev/between-api-and-form): OpenAPIのスキーマからフォームのバリデーションまで、型とコードを一気通貫で生成する方法を解説する。API定義と画面の型がずれる問題と、生成物を保守する手順を提示する。
- [プロパティベースドテスティングとは何か](https://kdot.co.jp/kdotdev/what-is-property-based-testing): プロパティベースドテスティングとは何かを、通常のユニットテストとの違いから解説する翻訳記事。満たすべき性質を記述し、値の生成を自動化する考え方と導入の判断を整理する。
- [私がNext.jsを使用しない理由](https://kdot.co.jp/kdotdev/why-i-wont-use-nextjs): Kent C. DoddsがNext.jsを採用しない理由を、フレームワークの責務とベンダーロックインの観点から整理する翻訳記事。採用判断で参照すべきトレードオフを提示する。採用前に確認したい決定事項を整理する。
- [SlackAppをVercelにデプロイする](https://kdot.co.jp/kdotdev/slackapp-vercel): SlackアプリをVercelにデプロイする手順を、Slack APIの設定からイベント購読、環境変数の登録まで整理する。ローカルでの検証後に本番へ反映する流れを提示する。
- [ts-morphを使ってコンポーネントとstorybookのファイルを自動生成](https://kdot.co.jp/kdotdev/ts-morph-react-storybook): ts-morphでReactコンポーネントとStorybookのstoryを自動生成する仕組みを、テンプレートの設計から解説する。既存コードの規約に合致するようファイルを出力する手順を提示する。
- [Reactサーバーコンポーネント移行前に知りたかったこと](https://kdot.co.jp/kdotdev/what-are-react-server-components): Reactサーバーコンポーネントへの移行を5万行のコードベースで実施した著者が、利点と制約を実例で解説する翻訳記事。移行前の設計判断を整理する。
- [ts-morphを使ってtailwindのレスポンシブ対応](https://kdot.co.jp/kdotdev/ts-morph-tailwind): ts-morphでTailwindのレスポンシブ対応を自動生成する方法を、設計から実装まで解説する。既存コンポーネントを走査し、ブレークポイントごとのクラスを生成する手順を示す。
- [NdArrayを例にPythonのTypeVarTupleの力を確認する](https://kdot.co.jp/kdotdev/ndarray-python-typevartuple): PythonのTypeVarTupleで可変長の型パラメータを表現し、NumPyのndarrayに形の情報を型として付与する方法を解説する。タプルの長さに応じて戻り値の型を変更する例を提示する。
- [npm・yarn・pnpm と npx の違い - どれをいつ使うか](https://kdot.co.jp/kdotdev/npm-yarn-pnpm-npx): npm・yarn・pnpmとnpxの違いを、インストール・ロックファイル・実行の観点で整理する。どの状況でどれを選択するかの判断基準と、Pythonのpoetryとの対応も提示する。モノレポでの選定方法も整理する。
- [Pythonのジェネレーター・コルーチンとasync/await](https://kdot.co.jp/kdotdev/python-generators-coroutines-native-coroutines-and-async-await): Pythonのジェネレーターとコルーチン、ネイティブコルーチン、async/awaitの関係を、yieldの進化から解説する翻訳記事。非同期処理がどのように実現されたかを整理する。
- [FastAPIリクエストごとのログ識別方法](https://kdot.co.jp/kdotdev/identifying-fastapi-requests-in-logs): FastAPIでリクエストごとにログを識別する方法を、リクエストIDの生成からLoguruへの記録、レスポンスヘッダーでの返却まで解説する翻訳記事。障害調査で追跡できる形にする。ログ相関の実装に活用できる。
- [polarsでstrのcapture groupを参照しつつreplaceする](https://kdot.co.jp/kdotdev/polars-str-capture-group-replace): polarsの文字列操作で、正規表現のキャプチャグループを参照しながら置換する方法を解説する。expr.str.replaceの記述方法と、複数グループを使用するときの注意点を提示する。
- [Lyftでのリアルタイム機械学習基盤の構築](https://kdot.co.jp/kdotdev/lyft): Lyftがリアルタイム機械学習基盤をどう構築したかを、オンライン推論と特徴量の更新を中心に解説する翻訳記事。ストリーミング処理とモデル配信の設計を整理する。
- [WTF Python!😱（Python、まじかよ！）後編](https://kdot.co.jp/kdotdev/wtf-python-2): 「What the f*ck Python」の日本語訳（後編）。前編に続いて、意外な挙動のスニペットを対象に、Pythonの動作原理と注意点を解説する。
- [WTF Python!😱 （Python、まじかよ！）前編](https://kdot.co.jp/kdotdev/wtf-python-1): Pythonの意外な挙動を集約した「What the f*ck Python」の日本語訳（前編）。予想外のスニペットを題材に、言語仕様の注意点と実行結果の理由を解説する。
- [Scalaで型レベルfizzbuzz](https://kdot.co.jp/kdotdev/scala-fizzbuzz): Scalaの型レベル計算でFizzBuzzを実装したメモ。shapelessを利用し、数値を型として処理しながら割り算と条件分岐を型レベルで表現する方法を整理する。
- [nextjs×reg-suitで画像が読み込まれない問題を解決する](https://kdot.co.jp/kdotdev/nextjs-reg-suit-image): next/imageをreg-suitの画像回帰テストで読み込むと失敗する問題を、next/imageをラップするコンポーネントとStorybookの設定で解決する手順を整理する。
- [FastAPIのAsyncClientテストで50xを例外にしない](https://kdot.co.jp/kdotdev/fastapi-asyncclient-50x): FastAPIのAsyncClientを使用したテストで、50xレスポンスが例外になるのを防止する方法を解説する。raise_app_exceptionsの設定と、エラー応答を検証するテストの記述方法を提示する。
- [fastapi-cacheでUnion型をキャッシュした際にdictが返却される問題](https://kdot.co.jp/kdotdev/fastapi-cache-union-dict): fastapi-cacheでUnion型をキャッシュするとdictが返却される問題を、シリアライズの復元過程から解説する。型情報を維持したままキャッシュするための設定と代替策を整理する。
- [Auth0のログをDatadogへ飛ばす with terraform](https://kdot.co.jp/kdotdev/auth-datadog): Auth0のログをDatadogに転送する構成を、Terraformで構築する手順と失敗した点から整理する。AP1リージョンで公式Integrationが使用できない場合の代替手段を対象とする。
- [FastAPIのAsyncClientテストでlifespanが実行されない問題](https://kdot.co.jp/kdotdev/fastapi-asyncclient-lifespan-events): FastAPIのテストでAsyncClientを使用するとlifespan eventsが実行されない原因を、httpxのASGI transportの設定から解説する。起動・終了処理をテストで実行する記述を提示する。
- [GitHub Actionsをなるべく安く使う](https://kdot.co.jp/kdotdev/github-actions): GitHub Actionsの課金を抑制するために、実行時間とジョブ構成を再検討する方法を整理する。renovateのPRで実行されるworkflowの削減、キャッシュ、self-hosted runnerの使い分けを対象とする。
- [Aurora PostgreSQLからSlowQueryをログに出す with terraform](https://kdot.co.jp/kdotdev/aurora-postgresql-slowquery-with-terraform): Aurora PostgreSQLのスロークエリをCloudWatch Logsに出力する設定を、Terraformのクラスターパラメータグループで構築する。familyの調査方法と、3秒超のステートメントを記録する手順を提示する。
- [GOでのロードバランサー作成](https://kdot.co.jp/kdotdev/building-a-load-balancer-in-go): Goでロードバランサーを実装する過程を、リバースプロキシの組み立てから解説する。リクエストの振り分け、ヘルスチェック、同時接続の扱いをコード例で示す。
- [2023年版・プロダクトマネージャー面接のポイント](https://kdot.co.jp/kdotdev/interviewing-for-product-manager-roles-in-2023): プロダクトマネージャー職の面接で問われるポイントを、2023年の傾向に沿って整理する。ケース質問の進行方法、経験の説明方法、企業側が参照する判断力を具体的に提示する。
- [SQLAlchemy基本的なRelationshipパターン](https://kdot.co.jp/kdotdev/sqlalchemy-relationship): SQLAlchemyのドキュメント翻訳から、基本的なrelationshipパターンを整理する。1対多・多対多・1対1の記述方法と、Mappedアノテーションでの宣言的マッピングを例で提示する。翻訳の注意点も付記する。
- [TypeScriptのanyはなぜ良くないのか、またその回避方法](https://kdot.co.jp/kdotdev/typescript-any): TypeScriptのanyが型安全性を損なう理由と、やむを得ず使用する状況への対処を整理する。unknownやジェネリクスへの置き換え、ESLintの禁止設定、外部入力での型検証の記述方法を提示する。
- [pytest高速化の秘訣](https://kdot.co.jp/kdotdev/pytest-speedup): pytestの実行を高速化するためのチェックリストを、ハードウェア・コレクション・I/O・並列化の観点で整理する。翻訳記事として、計測後に効果の上位から適用する手順を提示する。CIの実行時間を計測しながら導入する。
- [Rust対Go：実践的な比較](https://kdot.co.jp/kdotdev/rust-go): RustとGoで同じWebサービスを作成し、開発プロセスと実装の違いを比較する。型安全性・並行処理・ビルド時間・学習コストの観点から、どちらを選択するかの判断材料を提示する。
- [Auth0の403 user does not match subjectエラーにハマった話](https://kdot.co.jp/kdotdev/auth0-403-user-to-be-acted-on-does-not-match-subject-in-bearer-token): Auth0のManagement APIで403 user does not match subjectが出た原因を、client applicationとTerraformの設定から整理する。再発しないための確認点を提示する。
- [「Apache Arrow: データエンジニアリングの未来」](https://kdot.co.jp/kdotdev/Apache-Arrow-The-Future-of-Data-Engineering): Apache Arrowがデータエンジニアリングのどこを変えるのかを、列指向メモリ形式とゼロコピー転送の仕組みから解説する。異なる処理系の間でデータを転送するときの利点を整理する。
- [データからストーリーを引き出すためのテクニック９選](https://kdot.co.jp/kdotdev/9-techniques-to-discover-data-narratives): データからストーリーを引き出す9つのテクニックを用途別に紹介する。時系列・変数間の関係・比較・ドリルダウンなどを対象とし、分析結果を読み手へ伝わる形にする手順を整理する。
- [データサイエンティストのためのPythonライブラリ5選](https://kdot.co.jp/kdotdev/Python-Libraries-for-Lazy-Data-Scientists): データの前処理や可視化を容易にするPythonライブラリを5つ紹介する。面倒な作業を削減する目的別の用途と、データサイエンティストが最初に導入すべきライブラリを厳選した。
- [レートリミットアルゴリズムの世界](https://kdot.co.jp/kdotdev/the-world-of-rate-limit-algorightm): レートリミットの代表的なアルゴリズムを、固定窓・スライディングウィンドウ・トークンバケット・リーキーバケットの違いで整理する。分散環境での利用時の注意点も対象とする。
- [Pythonのジェネリクスで型が抽象化されたクラスやデータを定義する](https://kdot.co.jp/kdotdev/python): Pythonのジェネリクスで、型を抽象化したクラスやデータ構造を定義する方法を解説する。list[int]のような標準型からTypeVarを利用した自作クラスまで、なぜ必要なのかを例で提示する。型引数の制約も対象とする。
- [Pythonの型ヒントと共変・反変・不変(variance)](https://kdot.co.jp/kdotdev/python-covariance-contravariance-variance): Pythonの型ヒントにおける共変・反変・不変を、ジェネリクスの型パラメータがどこで安全かを基準に解説する。listとCallableの違いを通して、変性が実行時エラーを防止する理由を整理する。設計への活用も提示する。
- [Pythonの型エイリアス(type alias)で複雑な型をシンプルに扱う](https://kdot.co.jp/kdotdev/python-type-alias): Pythonの型エイリアスで型ヒントが複雑なときに別名を付与し、シグネチャの可読性を向上させる方法を解説する。TypeAliasの記述方法、ジェネリクスとの組み合わせ、使用時の注意点を対象とする。型の再利用で可読性を維持する判断も提示する。
- [PythonとNewType](https://kdot.co.jp/kdotdev/python-newtype): PythonのNewTypeで、値に意味を持たせて混同を防止する方法を解説する。実行時コストをほぼゼロに維持しながら、型チェックで値の確からしさを保証する設計を提示する。
- [fp-tsとoption](https://kdot.co.jp/kdotdev/fp-ts-option): fp-tsのOptionで、値の有無を型として管理する方法を解説する。SomeとNoneの作成方法、mapやchainなどの変換、getOrElseでの取り出しまでをコード例で整理する。
- [TypeScriptとHigher Kinded Type(高階型)](https://kdot.co.jp/kdotdev/typescript-higher-kinded-type): TypeScriptで高階型（Higher Kinded Type）をエンコードする方法を解説する。型システムでデータ型を抽象化する理由と、fp-tsなどで使用されるエンコード手法を段階的に提示する。
- [ZStream companion object API](https://kdot.co.jp/kdotdev/zstream-companion-object-api): ZIOのZStreamコンパニオンオブジェクトのAPIを、Eitherの吸収やアクセス、変換の用途別に整理する。ストリーム処理を構成するときに参照するリファレンスとして活用できる形にする。
- [fp-tsとMonoid](https://kdot.co.jp/kdotdev/fp-ts-monoid): fp-tsのMonoidを単位元を持つ二項演算として解説する。Semigroupとの関係、concatAllなどのコンビネータ、数値・文字列・配列のMonoidの作成方法をコード例で提示する。
- [fp-tsとOrd](https://kdot.co.jp/kdotdev/fp-ts-ord): fp-tsのOrdで、値の順序を型クラスとして管理する方法を解説する。compareが返すOrderingの意味、反射・反対称・推移のlaw、ソートやmin/maxへの組み込み方を提示する。
- [fp-tsとEq](https://kdot.co.jp/kdotdev/fp-ts-eq): fp-tsのEqで、値の等値性を型クラスとして管理する方法を解説する。equalsの定義と3つのlaw、構造的な比較を構成するコンビネータ、既存型への適用例を整理する。
- [fp-tsとSemigroup](https://kdot.co.jp/kdotdev/fp-ts-semigroup): fp-tsのSemigroupを、結合則を満たす二項演算として解説する。concatの使用方法、数値や文字列のインスタンス、複数のSemigroupを組み合わせるコンビネータをコード例で提示する。
- [TypeScriptと型クラス](https://kdot.co.jp/kdotdev/typescript-typeclass): TypeScriptで型クラスを表現する方法を、HaskellやScalaの考え方と比較しながら解説する。interfaceとジェネリクスによるエンコード、拡張性の確保、実装時の制約を整理する。
- [型レベル多項式の微分](https://kdot.co.jp/kdotdev/dotty-typelevel-derivative): Scala 3（dotty）の型レベル多項式への微分実装の過程を解説する。項と和の型表現、係数と乗数の操作、型レベルで計算を構成する際の再帰と停止条件を対象とする。
- [Polyfunctionでpartially applied typeを改善する](https://kdot.co.jp/kdotdev/dotty-polyfunction-partially-applied-type): Scala 3のpolyfunctionで、Scala 2系のpartially applied typeを改善する。長さを型として保持するSizedListを例に、headの型制約をpolyfunctionで表現する。
- [型レベル多項式](https://kdot.co.jp/kdotdev/dotty-typelevel-polynomial): dottyの型で型レベルの多項式とその足し算を定義する方法を解説する。enumで項と和を表現し、係数・乗数を型パラメータとして保持して計算を構成する手順を提示する。
- [Match Type](https://kdot.co.jp/kdotdev/dotty-match-type): dottyのMatch Typeで入力の型をパターンマッチして別の型へ写す方法を解説する。Scala 2系の型レベル実装と比較し、どのように簡潔になるかを例で提示する。
- [コンパイル時オペレーション](https://kdot.co.jp/kdotdev/dotty-compiletime-ops): Scala 3のscala.compiletime.opsにあるコンパイル時オペレーションを、リテラル型への算術・比較・文字列操作の用途別に整理する。型レベル計算を記述するときの参照として活用できる。
- [リテラル型(literal type)](https://kdot.co.jp/kdotdev/dotty-literal-type): Scala 3のリテラル型を数値・文字列・真偽値の型として扱う方法から解説する。型レベル計算やMatch Typeと組み合わせ、コンパイル時に値を制約する活用法を提示する。
- [今までに読んだ技術書まとめ(随時更新)](https://kdot.co.jp/kdotdev/tech-books): これまでに読んだ技術書を、言語・インフラ・設計の領域別に整理する。初心者が最初に読む一冊から、実務で使用する実装例まで、選書の判断材料になる感想を付記する。
- [[書評]Docker/Kubernetes 実践コンテナ開発入門](https://kdot.co.jp/kdotdev/docker-kubernetes-intro-bookreview): DockerとKubernetesの実践コンテナ開発入門を、これからコンテナを学ぶ読者の視点で書評する。対象範囲、サンプルの実務性、読み進める順序と注意点を整理する。
- [ScalaでAuxパターンをするときにはimplicitの順番に気をつけよう](https://kdot.co.jp/kdotdev/scala-aux-implicit-order-error): ScalaのAuxパターンでimplicitの定義順が原因になるコンパイルエラーを、再現する最小例とともに解説する。型レベル計算が失敗する理由と、宣言順を修正する処方を提示する。
- [Googleがinterfaceを好む理由](https://kdot.co.jp/kdotdev/google-typescript-interface): GoogleのTypeScript style guideがinterfaceを好む理由を、拡張性・宣言マージ・エラーメッセージの観点から整理する。type aliasとの使い分けを判断する材料を提示する。
- [代数的データ型Deep Dive in Scala](https://kdot.co.jp/kdotdev/adb-scala): Scalaの代数的データ型（ADT）を、積と和の型、パターンマッチ、型クラスとの関係から解説する。case classとsealed traitでデータを設計するときの判断基準を整理する。
- [Scala 3のchecked exceptionが入る理由](https://kdot.co.jp/kdotdev/dotty-checked-exception-motivation): Scala 3に入る可能性があるchecked exceptionの設計意図を、Ordersky氏の説明に沿って整理する。例外が型システムから漏れる問題と、正常系・異常系を型で分類する利点を対象とする。
- [Chrome × ReactでonMouseLeaveがうまく動かない問題](https://kdot.co.jp/kdotdev/chrome-x-reactでonmouseleaveがうまく動かない問題): ChromeとReactでonMouseLeaveが発火しない問題を、svgを包むコンポーネントの例で再現する。素早いカーソル移動でイベントが失われる原因と、回避策を整理する。
- [[書評]シェルスクリプト基本リファレンス](https://kdot.co.jp/kdotdev/shellscript-reference-review): シェルスクリプト基本リファレンスを、日常の運用で使用するコマンドの参照方法に焦点を当てて書評する。辞書としての使用方法、初学者の学習順序、実務での注意点を整理する。
- [[書評]Linuxのしくみ ～実験と図解で学ぶOSとハードウェアの基礎知識](https://kdot.co.jp/kdotdev/linux-os-book): Linuxのしくみを、OSとハードウェアの関係を実験で確認する書籍として書評する。プロセス・メモリ・ファイルシステムの章立てと、読後に何を理解できるようになるかを整理する。
- [pandasメモ](https://kdot.co.jp/kdotdev/pandas-memo): pandasでCSV/TSVを読み、SQLiteやDataFrameを行き来するときに使用する操作をメモとして集約する。read_csvの引数、to_sql、欠損値の管理を実例から参照できる形にする。
- [PySpark DataFrameメモ](https://kdot.co.jp/kdotdev/pyspark-dataframeメモ): PySparkでDataFrameを作成する方法を、RDD・list・pandasからの変換別に整理する。explodeで1レコードを複数行にする操作や、SparkSessionの使用方法も実例で提示する。
- [AWS Glue色々](https://kdot.co.jp/kdotdev/aws-glue-some): AWS GlueでJSONのテーブルを作成し、ジョブを実行するまでの手順を整理する。classificationの変更、GlueAppへのコード配置、S3からの読み込みで失敗しやすい点が要注意である。
- [VPCエンドポイント](https://kdot.co.jp/kdotdev/vpc-endpoint): VPCエンドポイントの種類と選択基準を、ゲートウェイ型とインターフェース型の違いから解説する。S3やDynamoDBへの接続を、VPC内から閉じたネットワークで実現する方法を整理する。
- [PySpark on AWS Glue](https://kdot.co.jp/kdotdev/pyspark-on-aws-glue): AWS GlueのPySparkジョブで、ジョブブックマークとtransformation_ctxの使用法を整理する。重複処理を防止する設定と、create_dynamic_frameの基本的な構成を提示する。
- [react digraph使い方](https://kdot.co.jp/kdotdev/react-digraph使い方): react-digraphで有向グラフのエディタを作成する方法を、nodesとedgesのデータ構造から解説する。nodeKeyの指定で失敗しやすい点と、D3ベースの操作に渡す値の作成方法を提示する。
- [非同期概略](https://kdot.co.jp/kdotdev/非同期概略): プロセス・スレッド・コルーチンの違いを、OSが割り当てる資源とスケジューリングの観点で整理する。非同期処理がどの層で待ちを管理するのかを、用語の対応関係から把握できるようにする。
- [DynamoDBのテーブル設計とクエリの考え方](https://kdot.co.jp/kdotdev/dynamodb): RDBとの違いからDynamoDBのテーブル設計を検討し、アクセスパターン先行でスキーマを決定する手順を解説する。項目サイズ・取得方法・インデックスの選定と、単一テーブルで設計する判断を実例を交えて整理する。
- [Python typehintテクニック](https://kdot.co.jp/kdotdev/python-typehint): Pythonの型ヒントでクラス自身を参照する方法や、前方参照を文字列で記述するテクニックを集約する。ジェネリクス・Protocol・TypedDictなど、実務での型表現の注意点を提示する。実務での使い分けも提示する。
- [Amplify使い方色々](https://kdot.co.jp/kdotdev/amplify-usage): AWS Amplifyで認証やバックエンドAPIを追加する手順を、カテゴリ単位のコマンドとCloudFormationの関係から整理する。フロントとの接続で失敗しやすい点も対象とする。
- [GOのテストフレームワークtestifyの使い方](https://kdot.co.jp/kdotdev/goのテストフレームワークtestifyの使い方): Goのテストでtestifyのassertとrequireを使用し、値の比較やエラーの検証を簡潔に記述する方法を整理する。EqualValuesとNotEqualValuesの違い、t.Runでテストを構造化する例を提示する。
- [Raspberry Pi向けGoクロスコンパイルのDockerfile例](https://kdot.co.jp/kdotdev/ラズパイ向けにcgo_enabledしながらgoをクロスコンパイル): CGO_ENABLEDを有効にしたままRaspberry Pi向けのGoバイナリをクロスコンパイルするDockerfileの例。arm向けのビルド環境と実行コマンドを整理したメモ。
- [Go tips](https://kdot.co.jp/kdotdev/go-tips): Goでnullableな値の処理にpointerを使用する理由と、JSONやDBスキーマとの対応を整理する。ゼロ値との区別、omitemptyの挙動、interfaceのnil判定などで失敗しやすい点を整理する。
- [amchartsとjestの併用](https://kdot.co.jp/kdotdev/amchartsとjestの併用): JestでamChartsを使用したテストを記述すると失敗する問題を、設定の追加で解決する手順を整理する。transformIgnorePatternsの調整と、React側の依存を再導入する手順を提示する。
- [Pythonのproperty based testingライブラリhypothesisの使い方](https://kdot.co.jp/kdotdev/pythonのproperty-based-testingライブラリhypothesisの使い方): Pythonのproperty based testingライブラリHypothesisで、値の生成とテストの記述方法を解説する。givenとstrategies、buildsによるオブジェクト生成、失敗例の再現方法を対象とする。
- [monocle-tsでtraverse](https://kdot.co.jp/kdotdev/monocle-tsでtraverse): monocle-tsのTraversalとtraverseで、複数の対象をまとめて変換する記述方法を整理する。Lensとの役割の違いと、合成して使用するときの型の読み方をメモする。
- [Reactパフォーマンス・チューニングチートシート](https://kdot.co.jp/kdotdev/react-performance): Reactのパフォーマンスを計測し、無駄な再レンダリングを削減するためのチートシート。計測の起点、memoやuseMemoの適用箇所、差分検出の仕組みを実例で整理する。
- [ramda.jsでよく使う関数](https://kdot.co.jp/kdotdev/ramda-js-heavyuse): ramda.jsでよく使用する関数を、オブジェクトの射影・等価判定・関数合成の用途別に整理する。pipeとcomposeの違い、mapやfilterと組み合わせる記述方法を例で提示する。
- [pytestでよく使うプラグイン](https://kdot.co.jp/kdotdev/pytest-plugin): pytestでよく使用するプラグインを、並列実行・カバレッジ・モックの用途別に整理する。pytest-xdistの導入で高速化する理由と、DBなど副作用があるテストでの注意点を解説する。
- [styled-componentsドキュメント日本語訳② Advanced](https://kdot.co.jp/kdotdev/styled-components-documentationadvanced): styled-componentsのAdvanced Usageを日本語訳する。ThemeProviderによるテーマ、Refsの受け渡し、SSRでの注意点を、原文の例に沿って整理する。
- [styled components documentation日本語訳①ーBasicsー](https://kdot.co.jp/kdotdev/styled-components-documentationbasics): styled-componentsのBasicsを日本語訳する。スタイル付与、propsによる動的な値、既存コンポーネントの拡張を例で提示する。
- [PythonでJavascriptの様な分割代入](https://kdot.co.jp/kdotdev/python-distruction): JavaScriptの分割代入に相当する操作をPythonで実現する方法を解説する。辞書から特定のキーだけを抽出する記述方法と、関数引数でのテクニックを例で提示する。
- [systemctlの使い方](https://kdot.co.jp/kdotdev/systemctl-usage): systemdのunitファイルを記述してサービスを登録し、systemctlで起動・停止・ログ確認する手順を整理する。UnitとServiceの主要ディレクティブ、自動起動の設定を対象とする。
- [【初めてのGraphQL】解決できる課題とそのユースケースについて](https://kdot.co.jp/kdotdev/graphql-intro): GraphQLが解決する課題を、RESTとの違いとユースケースから解説する。スキーマとクエリの基本、グラフとしてのモデリング、導入すべき用途と、避けるべき用途を整理する。
- [Pipenvの使い方](https://kdot.co.jp/kdotdev/pipenv-usage): PipenvでPythonの仮想環境と依存関係を管理する方法を、インストールからロックファイルの扱いまで整理する。requirements.txtからの移行と、実行時の仮想環境の使い方を示す。
- [redux-sagaまとめ](https://kdot.co.jp/kdotdev/redux-sage): redux-sagaの主要なAPIを、take・put・call・forkの役割と副作用の管理方法から整理する。アクションを待機する処理、並行実行、キャンセルの記述方法を例で整理する。
- [pyrightの使い方](https://kdot.co.jp/kdotdev/pyright-usage): pyrightの使い方をインストールから設定ファイルの記述まで整理する。VS CodeのPylanceとの関係、CIでの実行、型エラーの読み方とstrictモードへの移行手順を解説する。設定の実例も提示する。
- [Scalaでcsvをexcelで開くときにUTF-8で解釈させ文字化けを防ぐ方法](https://kdot.co.jp/kdotdev/scalaでcsvをexcelで開くときにutf-8で解釈させ文字化けを防ぐ): ExcelでCSVを表示するときにUTF-8として解釈させるため、BOMを付与して出力する方法をScalaで解説する。文字化けの原因と、ファイル出力時のエンコーディング指定を整理する。
- [pythonでdynamo dbをORM風に扱えるpynamodbの使い方](https://kdot.co.jp/kdotdev/pynamodb): PythonでDynamoDBをORM風に操作できるPynamoDBの使用方法を、テーブルクラスの定義から解説する。Metaクラスの設定、キーの指定、CRUDの記述方法を例で提示する。検索と更新の実装を対象とする。一覧取得のクエリも付記。
- [TypedDictでpythonのtype hintでdictのkeyとvalueに厳格に型をつける](https://kdot.co.jp/kdotdev/python-typed-dict): TypedDictでPythonのdictにkeyとvalueの型を厳密に付与する方法を解説する。pyrightのstrictモードで確認し、ネストしたdictや必須・任意キーを表現する例を提示する。型の再利用にも言及する。
- [PythonでPhantom Type(幽霊型)を使って静的にプログラムの欠陥を発見する](https://kdot.co.jp/kdotdev/pythonphantom-type): Pythonの型ヒントでPhantom Type（幽霊型）を表現し、mypyやpyrightで静的に誤りを検出する方法を解説する。型パラメータに意味を付与し、値の混同を防止する設計を提示する。
- [[初級-中級向け]Scala基本APIを完全に理解するシリーズ② -Either編-](https://kdot.co.jp/kdotdev/scalaapi-either): ScalaのEitherをRightとLeftの使い分けからmap・flatMap・for式まで解説する。Optionとの違い、エラー情報を保持する設計、実務でのユースケースを整理する。Eitherの注意点も提示する。
- [[初級-中級向け]Scala基本APIを完全に理解するシリーズ① -Option編-](https://kdot.co.jp/kdotdev/scalaapi-option): ScalaのOptionをSomeとNoneの基本からmap・flatMap・getOrElseまで解説する。メソッドの重要度をランク付けし、nullを回避する設計での使用例を提示する。null安全性の判断に活用できる。
- [「意識」読んだ](https://kdot.co.jp/kdotdev/read-consciousness): 「意識」を題材に、脳科学の実験から意識のハードプロブレム、哲学的ゾンビ、意識の力をどう判断するかを整理する。読後の疑問と、本書の議論の構成を整理する。
- [0からScalaを本番導入して感じたこと・考えたこと](https://kdot.co.jp/kdotdev/scala-introduction): Scalaを知識ゼロの状態から本番導入し、1年運用して得た知見を整理する。言語選定の理由、学習コスト、チームへの展開方法、導入後に感じた利点と課題を対象とする。導入を検討するチームが判断に活用できる材料になる。実務での変化も付記する。
- [ZIO小史](https://kdot.co.jp/kdotdev/zio-history): ZIOの作者John A De Goesによる「A Brief History of ZIO」の日本語訳。非同期effectシステムからZIO Environmentまでの設計の変遷を、当時の課題とともに解説する。
- [ZIOへの環境Rのprovide方法各種](https://kdot.co.jp/kdotdev/ziorprovide): ZIOのDIで環境Rをprovideする方法を、provide・provideLayer・provideSomeなどのAPI別に整理する。ZLayerとHasによる依存の構成方法を例で提示する。
- [Goにproperty based testingを布教したい](https://kdot.co.jp/kdotdev/go-pbt-testing): Goにプロパティベースドテスティングを普及させるための導入記事。HaskellのQuickCheckから始まった考え方と、Goで利用できるライブラリ、テストの記述方法を整理する。
- [技術書を読む技術](https://kdot.co.jp/kdotdev/技術書を読む技術): 技術書を読み切るための進め方を、読む前の準備・読む順序・実践するタイミングに分類して整理する。勉強が苦手なエンジニアでも読書を技術として再現できるようにする。
- [SSHの使い方](https://kdot.co.jp/kdotdev/sshの使い方): SSHのポートフォワーディングと鍵作成を、踏み台サーバーを経由する接続例から整理する。ローカル転送・リモート転送の違いと、sshコマンドのオプションを実務利用に即した形で解説する。
- [爆速python-fire](https://kdot.co.jp/kdotdev/爆速python-fire): Google製ライブラリpython-fireで、Pythonの関数やクラスをそのままCLIコマンドにする方法を解説する。argparseの記述なしに、複数コマンドとサブコマンドを構成する例を提示する。
- [Scalaへの移行 -ウォルマート・カナダへの導入で学んだこと-](https://kdot.co.jp/kdotdev/scala-walmart): Scalaへの移行を、ウォルマート・カナダの事例から学ぶ。なぜ関数型言語を選択したのか、チームの習熟をどう推進したか、移行で得た成果と残存課題を整理する。
- [ScalaのF[_]と高カインド型を理解する](https://kdot.co.jp/kdotdev/scala-higher-kinded-type): ScalaのF[_]と高カインド型（Higher Kinded Type）を、型の抽象化を段階的に整理して解説する。FunctorやMonadの型クラスがなぜF[_]を要求するのかを理解する。
- [VPC内で動くGlue開発エンドポイントでPyCharmを使用する方法](https://kdot.co.jp/kdotdev/vpc-glue-pycharm): VPC内で動作するAWS Glueの開発エンドポイントに、PyCharm Professionalから接続する手順を整理する。VPC外向けの公式手順との違い、踏み台とセキュリティグループの設定を対象とする。
- [Scalaのシングルトン型(~.type)について](https://kdot.co.jp/kdotdev/scala-singleton-type): Scalaのシングルトン型（~.type）が何を表すのかを、オブジェクトの型としての意味から解説する。型パラメータやパス依存型での利用例と、読み方の要点を整理する。
- [Scala summoner pattern](https://kdot.co.jp/kdotdev/scala-summoner-pattern): Scalaのsummoner patternで、型クラスのインスタンスをimplicitで解決する記述を整理する。Semigroupを例に、applyメソッドを定義して呼び出しを簡潔にする利点を提示する。
- [shapelessでフィールドの順番の違うcase classを自動で変換する](https://kdot.co.jp/kdotdev/shapeless-convert-with-field): shapelessで、フィールドの順番が違うcase class同士を自動変換する方法を解説する。LabelledGenericとHListを利用し、フィールド名が一致すれば変換用の型クラスを作成する。
- [サルでもわかるカリー化とそのメリット](https://kdot.co.jp/kdotdev/monkey_curry): カリー化の定義と、なぜ関数型プログラミングで使用されるのかを、アロー関数の例から解説する。複数引数の関数を1引数ずつの関数に分解する利点と、部分適用の方法を提示する。部分適用とカリー化の違いも整理し、実務での利用例を提示する。
- [Rubyの型解析ライブラリSorbet事始め](https://kdot.co.jp/kdotdev/ruby_sorbet): Stripe製のRuby型解析ライブラリSorbetの導入を、Getting Startedに沿って整理する。sigの記述方法、型チェックの実行、既存コードへ段階的に型を付与する手順を解説する。
- [cats-effectv3.0.0がリリースされたらしい](https://kdot.co.jp/kdotdev/cats-effectv3-0-0): cats-effect 3.0.0のリリースで何が変わったのかを、再設計のポイントから整理する。ContextShiftやTimerのimplicit依存の解消、パフォーマンスとインターフェースの変更を対象とする。
- [shapelessを使って同じ様なcase classを自動で変換する](https://kdot.co.jp/kdotdev/shapelessを使って同じ様なcase-classを自動で変換する): shapelessで、似た形のcase classを自動変換するmapToの実装過程を解説する。HList表現が同一という条件、MapTo型クラス、LabelledGenericによる導出を対象とする。
- [ScalaのAuxパターン](https://kdot.co.jp/kdotdev/scalaのauxパターン): ScalaのAuxパターンで、型クラスインスタンスの依存関係を型メンバーとして表現する方法を解説する。型クラス同士が依存する状況で、型の対応を維持したままインスタンスを選択する記述を提示する。
- [Scalaのジェネリックライブラリshapelessの基本](https://kdot.co.jp/kdotdev/scalaのジェネリックライブラリshapelessの基本): Scalaのshapelessによるジェネリックプログラミングの基本を、HListとLabelledGenericから解説する。型レベルの構造を扱うための考え方を整理し、最初に押さえるAPIを提示する。
- [タイミング攻撃の仕組み](https://kdot.co.jp/kdotdev/タイミング攻撃の仕組み): タイミング攻撃の仕組みを文字列比較にかかる時間差から解説する。HMACのトークン検証を例に、攻撃が成立する条件と、定数時間比較で防止する方法を整理する。
- [ZStreamとFs2Streamを相互変換する](https://kdot.co.jp/kdotdev/ziostreamとfs2streamを相互変換する): ZIOのZStreamとfs2のStreamを相互変換する方法を、zio.stream.interopのfs2zで解説する。ZIO製サーバーでwebsocketを対象とするときの実装手順を提示する。
- [PythonのEllipsis(...)とtype hints](https://kdot.co.jp/kdotdev/python-ellipsis-type-hints): PythonのEllipsisがtype hintsで何を意味するのかを、可変長引数・タプル型・スタブファイルの用途別に解説する。省略記号が型として使用される状況と読み方を整理する。