【Inventor】例外がある場合の部品表並べ替え

部品表（BOM）の「ソートで数字とアルファベットや記号が混ざると順序がバラバラになる」というのは、Inventorに限らず多くのCADやExcelで発生する共通の悩みですね。

これは、システムが「数値」としてではなく「文字列（テキスト）」として1文字ずつ比較しているために起こる現象です。

これを解決し、「フィルターやソートをかけた瞬間に理想の順序に並ぶ」ようにするには、「ソート専用の隠し番号（重み付け）」をiLogicで自動生成して、その列で並べ替える手法が最も確実です。

目から鱗解決のロジック
システムの根幹を守りつつ、将来の自動化へ「種」をまく

目から鱗解決のロジック

以下のようなイメージで運用します。

モデル（パーツ/アセンブリ）:iPropertiesのカスタムタブに Sort_ID などの名前で新しい項目を作り手動、またはiLogicで作る。
部品表（図面のパーツ一覧）:「列選択」で Sort_ID を追加する。（※図面には出したくないなら、列幅を0にするか非表示にする）
一つ一つの部品を開いてカスタムプロパティを作るのは苦行です。
ここはiLogicの出番です。
iLogicで変換: 「250-1」や「301A」という数字＆記号、数字＆文字など複雑な番号を、ソートしやすい「純粋な数値」に変換して Sort_ID に書き込みます。
- 例：150 → 150.00
- 例：150-1 → 150.01
- 例：301K → 301.99（Kは後ろに持っていく、など）
ソートの実行:パーツ一覧の編集画面にある「並べ替え」機能で、Sort_ID を優先順位1位に設定する。

「内職」を「設計」に変える、iLogicという名の翻訳機

「毎回ドラッグして並べ替える数秒」を笑う人は、その数秒の間に「人間が本来考えるべき設計の思考」が途切れるリスクを理解していません。

「数字のみではない番号」という例外を、iLogicという「翻訳機」を通してコンピュータが理解できる「純粋な数値」に変換してあげることができれば毎回1つずつ手作業でドラッグしていたあの内職をサッと並び替えてくれるツールのできあがり！

具体的な「翻訳のレシピ（コード）」は以下の通りです。

iLogicで「一括付与」

' ==========================================================
' 【iLogic】部品番号（図番）を数値化し、安全にSort_IDへ書き込む
' ==========================================================

' 1. 値を保持する変数の宣言
Dim partNumber As String = iProperties.Value("Project", "Part Number")
Dim sortValue As Double = 0

' 部品番号が空の場合は、後続の計算ができないため終了
If String.IsNullOrEmpty(partNumber) Then Return

' 2. 計算ロジック（図番をソート可能な数値へ変換）
Try
    If partNumber.Contains("-") Then
        ' 例: "150-1" -> 150.01 に変換
        Dim parts() As String = partNumber.Split("-"c)
        sortValue = CDbl(parts(0)) + (CDbl(parts(1)) / 100)
    ElseIf partNumber.EndsWith("K") Then
        ' 購入品などを末尾に飛ばす設定（例: 301K -> 301.99）
        Dim numPart As String = partNumber.Replace("K", "")
        sortValue = CDbl(numPart) + 0.99
    Else
        ' 純粋な数字のみ
        If IsNumeric(partNumber) Then
            sortValue = CDbl(partNumber)
        End If
    End If
Catch
    ' 予期せぬ形式の図番は、大きな数値にしてリストの最後に配置
    sortValue = 99999
End Try

' 3. API（PropertySet）を使用した堅牢な書き込み
' カスタムプロパティの「住所」を直接特定して操作します
Dim oCustomPropSet As PropertySet = ThisDoc.Document.PropertySets.Item("Inventor User Defined Properties")

Try
    ' 既存のプロパティがある場合は値を更新
    oCustomPropSet.Item("Sort_ID").Value = sortValue
Catch
    ' プロパティ自体が存在しない場合は、新規に定義を追加
    ' これにより、テンプレート外の古いファイルでもエラー停止しません
    oCustomPropSet.Add(sortValue, "Sort_ID")
End Try

' 変更を反映
InventorVb.DocumentUpdate()

このコードが「システム的に堅牢」と言える3つのポイント

「なぜわざわざ下のAPIを使っているの？」と思ったのではないでしょうか?

エラーによる業務停止の防止：
通常の iProperties.Value 命令は、項目が存在しないと即座にルールがクラッシュ（停止）します。
このコードは「無ければ作る」という自己修復機能を持っているため、数千個の部品をバッチ処理しても止まりません。
データベース構造への準拠：
Inventorの内部データベースの正しい階層（PropertySet）を辿って操作しているため、他チームが作ったファイルや、外部から届いた古いデータに対しても、一貫した動作を保証します。
「五月雨式」の回避：
APIで「型（Double）」を明示して書き込むことで、数値として正しくソートされます。
テキストとして適当に書き込まれるのを防ぎ、VaultやPDMへの影響も最小限に抑えられます。

iLogicとAPIの使い分け解説

「iLogicは『扉のノブ』、APIは『鍵そのもの』だ。」

初心者はiLogicの便利なショートカットを使えばいい。
しかし、組織の標準を作るエンジニアは、APIをiLogicの中に組み込むことで、エラーという名の『設計のノイズ』を消し去る必要がある。

まずは、アセンブリ内の全パーツにこの Sort_ID を「とりあえず 100」とかで一括で放り込むコードから始めてみてはいかがでしょうか？

システムの根幹を守りつつ、将来の自動化へ「種」をまく

カスタムプロパティは、設計者が自由に追加できる「白紙のメモ帳」のようなものです。
ここを使う分には、システムの根幹を壊すリスクが極めて低いため、非常に安全な「DXの遊び場」になります。

なぜ「DXの遊び場」かって？
それは現場レベルでこの「種」をまき、データを蓄積しておくこと。

いつか会社のシステムがアップデートされた際、
「たまたまこの項目を読み取って自動集計してくれたら……」という、未来への戦略的な期待を込めているからです。

そして何より「システムには迷惑をかけない。でも図面は劇的に使いやすくする。」

これが、私の考える現場主導の設計DXです。