<aside> 3️⃣

Phase 3 加工設計を“成果物”として引き渡せる形にする

ここまでで、私たちは

• 判断を構造化し
• 現実と接続し
• 差分を可視化し
• 改善ループを回す

状態を作りました。

Phase3では、その判断を外部に引き渡せる形にします。

</aside>

<aside> ❓

まず、G-codeとは何か

G-codeとは、CNCマシンを実際に動かすための命令言語です。

例えば、

• どの座標に移動するか
• どの速度で削るか
• どの工具を使うか

といった情報を、マシンが理解できる形式で記述したものです。

最終的にマシンを自動化するためには、

このG-codeを自動生成することが不可欠です。

ではなぜ、今それをゴールにしないのでしょうか。

</aside>

<aside> ⛔

なぜ、まだG-codeを出さないのか

理由はシンプルです。

G-codeは「最終出力」です。

しかし私たちが今構築しているのは、「判断の構造」です。

G-codeは、工程設計が確定した後の“翻訳結果”です。

もし工程設計の骨格が曖昧なままG-codeを生成すれば、

• 間違った段取り
• 不適切な加工順
• 危険な加工条件

をそのまま高速に量産することになります。

これは、自動化ではなく「焦りから生まれる致命的な誤りの量産」です。

だからこそ今は、

マシンへの命令ではなく、人間の思考構造を安定させること

を優先します。

</aside>

<aside> 🎯

Phase3のゴール

ゴールは明確です。

CAM担当者が「ゼロから考えなくていい状態」を作ること

CAMとは、G-codeを生成するためのソフトウェアです。

現場では、CAM担当者が図面を見て工程設計を行い、その後G-codeを生成しています。

現在、最も時間がかかっているのは「工程設計」の部分です。

• どの面を基準にするか
• 段取りは何回必要か
• どの順番で加工するか
• どんな工具カテゴリを使うか

この思考が毎回ゼロから行われています。

Phase3では、この思考部分を構造化し、引き渡せる形にします。

</aside>

<aside> ①

① ラベリング体系を固定する

まず行うのは、曖昧さの排除です。

「深い」「薄い」といった感覚的な表現を、数値に固定します。

例：

• depth > 30mm → deep_pocket
• wall_thickness < 2.5mm → thin_wall
• depth/diameter > 4 → high_aspect_hole

これは、判断の辞書を確定する作業です。

曖昧さが残る限り、再現性は生まれません。

</aside>

<aside> ②

② 工程順序を“形式化”する

次に、工程の構造を出力として固定します。

例：

{
  "setup_count":2,
  "setups": [
    {
      "datum":"Top",
      "operations": [
        {"feature":"F1", "type":"roughing", "tool":"flat_endmill"},
        {"feature":"F2", "type":"drilling", "tool":"drill"}
      ]
    }
  ]
}

重要なのは、以下が明示されていることです。

• 段取り回数
• 基準面
• 加工順
• 工具カテゴリ
• リスクフラグ
• 判断理由

これは「マシン命令」ではなく、

加工の設計図

です。

</aside>

<aside> ③

③ CAM担当者との実地テスト

最低3〜5案件で、実地テストを行います。

1. 工程設計出力を渡す
2. CAM担当者がプログラムを作成する
3. 所要時間を測定する
4. 修正箇所をログ化する

ここで測るのは、理論の正しさではありません。

現場で使えるかどうか

です。

</aside>

<aside> ④

</aside>

<aside> 📌

</aside>