検索結果

🧭 はじめに SOTIF（Safety Of The Intended Functionality）は、自動車の先進運転支援（ADAS）や自動運転（AD） のようなシステムにおいて、 「故障していないのに」 「設計通りに動いているのに」 「それでも危険になる」 というタイプの安全課題を扱う考え方・規格です。 規格としては ISO 21448 が SOTIF に対応します。 SOTIF は ISO 26262（機能安全）と対立するものではなく、26262ではカバーしづらい危険領域を補う位置づけです。 🧩 まず結...

🧭 はじめに ADAS（Advanced Driver Assistance Systems）は、日本語では一般に 先進運転支援システムと呼ばれます。 一言でいうと、ADASは「運転という人間のタスクのうち、一部をクルマ側が支援する機能群」です。 重要なのは、ADASは自動運転（Autonomous / Automated Driving）そのものではなく、基本的に “運転者が主体である”ことを前提にした支援だという点です。 ADAS は「運転を代わりにやる」ではなく、運転の失敗を減らす／負担を減らす方向の技術とし...

0) 起動〜前処理 CLI 引数を解釈（-i <yaml> 必須） ロギング初期化（ログは stderr / stdout とは分離） 入力ファイル存在チェック（無ければ入力エラーで即時終了） 1) YAML 読み込み（入力→ドメイン） YAML を読み込み、ドメインモデル（Book/Chapter/Page）へ変換 ここでトリム等の正規化（前後 trim）は 変換時に実施（以後は正規化済みを前提にする） 2) ドメイン検証（API を叩く前に止める） 必須チェック・型チェック・重複チェックなど（要件にあ...

4.1 BookStack API の使用エンドポイント整理 本ツール（Book/Chapter/Page の骨格生成）で利用するエンドポイントは最小限に絞る。 一覧取得系（同一性判定・SKIP判定のための現状取得） GET /api/books/{book_id} Book直下の Page と Chapter の“並び”を content から取得する前提 原則これ1本で足りる設計とし、追加の list 取得は増やさない 作成系（骨格生成の本体） POST /api/chapters（Chapter...

5. エラーモデル設計 本章では、本ツールにおけるエラーの分類、扱い方、および どこで捕捉し、どこで処理を終了するかの境界を定義する。 本ツールは「安全側・再実行可能」を最優先とし、 エラー発生時は即時終了する fail-fast 方針を採用する。 5.1 エラー種別の分類 5.1.1 入力エラー（YAML / バリデーション） YAML の内容に問題があり、再実行しても成功しないエラーを入力エラーとする。 対象 YAML ファイルが読めない YAML 構文エラー YAML定義書.md に定義された以...

6.1 実行ファイル名と基本形式 6.1.1 実行ファイル名 実行ファイル名は create_skeleton.py とする。 6.1.2 基本コマンド形式 python create_skeleton.py -i path/to/input.yaml 6.2 引数仕様 6.2.1 オプション一覧 オプション 必須 値 説明 -i / --input 必須 ファイルパス 入力 YAML ファイルパス 6.2.2 入力ファイルパスの取り扱い -i/--input は 必須。 相対パス／絶...

ロギング設計 本章では、本ツールにおけるログの目的、出力先、ログレベル、および 標準出力との役割分担を定義する。 本ツールは CLI ツールであり、 人間が標準出力を見て結果を確認し、ログは問題発生時の調査に使う という役割分離を前提とする。 ロギングの基本方針 ログは デバッグ・原因追跡用途に限定する 標準出力は 処理結果（OK / SKIP / ERROR）のみを出す ログと標準出力は 混在させない ログと標準出力の責務を分離することで、 実行結果の可読性と障害調査のしやすさを両立できる。 ログ...

はじめに 本ページでは、添付された 要件定義書・YAML定義書・ソフトウェア仕様 を前提として、 BookStack の本・章・ページ骨格を自動生成する Python スクリプトを実装するための 作業分解構造（WBS） を示す。 ここでの WBS は、 実装順がそのまま理解できること 設計済み仕様（責務分割・fail-fast・安全側）と整合していること BookStack 上の記事として「後から見返しても実装の全体像が即座に把握できる」こと を目的としている。 全体フェーズ構成 フェーズ0：事前整理・方針...

要件定義 超上流から始めるIT化の原理原則 17か条：https://www.ipa.go.jp/archive/publish/qv6pgp0000000xa0-att/000005109.pdf ユーザーのための要件定義ガイド：https://www.ipa.go.jp/archive/publish/qv6pgp0000000wrt-att/000079352.pdf セキュリティ 安全なWebサイトの作り方：https://www.ipa.go.jp/security/vuln/websecurity...

要件定義書（テンプレート：小規模Excelツール） 1. 概要 1.1 背景・目的 背景： 目的（何を解決するか）： ゴール（成功条件）： 1.2 スコープ 対象業務： 対象外（やらないこと）： 1.3 用語定義 用語 意味 2. 利用者・利用シーン 2.1 想定ユーザー 利用者（例：経理担当、営業事務など）： PCスキル前提（例：Excel基本操作は可能、マクロは不可など）： 2.2 利用シーン いつ使うか（頻度）： どんな入力を受けて、何を出すか： 1回の作業時間目安： ...

🧭 はじめに 本章では、自民党における「派閥政治」とは何であったのかを整理する。 派閥は単なる仲良しグループでも、単純な権力争いの装置でもない。それは日本型政党システムの内部に組み込まれた制度的な権力配分メカニズムであり、長期政権を支えた統治装置でもあった。 本章では、 派閥の定義と日本型政党の構造的特徴 派閥が担った具体的機能 派閥をどう評価すべきか 本書の分析視角 を明確にする。 📚 派閥の定義と日本型政党の特徴 🏛 派閥とは何か 自民党の派閥とは、党内の議員グループであり、以下の特徴を持つ。 領袖（派...

🧭 はじめに 本章では、派閥政治を「文化」ではなく制度の帰結として捉える。 なぜ自民党では派閥がこれほど強固に形成されたのか。それは政治家の性格や日本人の気質ではなく、選挙制度が作り出した合理的行動の結果である。 本章では、 中選挙区制が生んだ党内競争 「数は力」という派閥拡大の合理性 1994年政治改革の狙い 小選挙区制でも派閥が残った理由 比例復活制度と派閥インセンティブ を制度分析の視点から整理する。 🏛 中選挙区制と党内競争 📊 中選挙区制とは何だったか 1994年の政治改革以前、衆議院選挙は中選挙区...