見出し画像

AppSuite APIをGASで使う の前に

so-mu

設定編の5回目(最終回)は8.6へのバージョンアップ後に書きます。
今回は設定編に続きAPIの具体的利用に関する記事の前段階として伝えておきたいことになります。

APIの前に、AppSuite内で完結させる構築

　APIの説明をする前に、”第一はAppSuiteの中で完結すべきである”というのがベストであると言っておきたい。生成AIの利用が可能になり、いくらAPIが使いやすくなったとはいえ、誰でも使えるというわけでは無く、あくまでAppSuiteをより使いやすくするための手段でしかないので、構築・保守・運用の継続性からAppSuite以外の能力が当たり前に求められる様な状況は望ましくない。
　とはいえAppSuiteの開発・利用が進むほど、外部サービスとつなぐにはAPIを利用せざるを得ない場面は増えるのも間違いない。ただしAPI以外にも連携手段としてはCSV(+RPA)による手動連携や、コストはかかるがIFTTT、Zapierなど別のサービスを使っての連携もあるので、運用や社内体制次第でどこまでAPIを利用するかという判断が求められる。
ベンダーから聞いたkintoneの利用者の話ではあるが、一切プラグインを利用しない運用を行っている会社があるという。せっかくのkintoneの拡張性を犠牲にしてでも、自主運用の継続性を重視する方針ということだ。(拡張性が削がれている時点で、コスト比較でkintoneからAppSuiteへ乗り換えたほうが良いとは思うが)
極めて少人数でのノーコード開発は、しっかりした仕様書が無い限り、形を変えた野良excelマクロや野良RPAでしかない。弊社でもAPI利用を拡大していくのは人員的にリスクがあるが、事務コストの削減のため開発は続ける方針である。しばらくはNoteに公開できるレベルで仕様書の作成を進めていくしかないと考えている。


以下の記事にはプログラムソースが出てきているが、動作検証しておらず、今回の主題ではないのでソース部分は読み飛ばし推奨。

なぜGASなのか

　開発者自身による保守はともかく、非プログラマで保守のハードルが低い言語は何かと考えたときに、スプレッドシートとの相性が良いGASを選択した。従前にEXCEL VBAで開発していた時に非プログラマではスプレッドシートを経由してひとつづつの成果が見えやすいのがよいと強く感じたのが大きな理由になる。
GASのコードを例示する際も、基本的にはスプレッドシートへ展開、またはスプレッドシートから読み取って処理を行うようにしている。
ただし、スプレッドシートへのアクセスは処理時間がかかるため、処理数によってはGAS特有の6分の壁を考慮しなくてはならず、アクセスは最小限に抑えるべきというのも付記しておく。

生成AIをうまく利用しよう

　GASは様々なAPI利用可能なサービスのオフィシャルでサンプルプログラムが提供されていないことがほとんどなので、生成AIを使ってGASへ変換・改良していくことで、実装していくのがいいのではないかと思う。

curl 'https://local.yourdomain/cgi-bin/dneo/appsr.cgi' \
-H 'X-Desknets-Auth: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' \
-d action=list_data \
--data-urlencode app_id=@sample_app \
--data-urlencode 'fields=[{"field_name":"担当"},{"field_alias":"customer"}]' \
--data-urlencode 'filter={"item":[{"field_id":"105","operator":"=","value":"-1 months:*"}]}' \
--data-urlencode keyword=山田 \
-d sort_field_id=101 \
-d sort_order=asc \
-d offset=0 \
-d limit=100

　例えばAppSuiteのオフィシャルでは上の様にCurlとPowerShellでAPI利用のスクリプトが例示されているが、これをChat-GPTを使ってGASに変換してもらったものが次のコードになる。

function fetchDataFromDesknets() {
  var endpointUrl = 'https://local.yourdomain/cgi-bin/dneo/appsr.cgi';
  var headers = {
    'X-Desknets-Auth': 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
    'Content-Type': 'application/x-www-form-urlencoded'
  };

  var payload = {
    'action': 'list_data',
    'app_id': '@sample_app',
    'fields': JSON.stringify([{"field_name":"担当"},{"field_alias":"customer"}]),
    'filter': JSON.stringify({"item":[{"field_id":"105","operator":"=","value":"-1 months:*"}]}),
    'keyword': '山田',
    'sort_field_id': '101',
    'sort_order': 'asc',
    'offset': '0',
    'limit': '100'
  };

  var options = {
    'method': 'post',
    'headers': headers,
    'payload': payload
  };

  try {
    var response = UrlFetchApp.fetch(endpointUrl, options);
    Logger.log(response.getContentText());
  } catch (e) {
    Logger.log('Error: ' + e.message);
  }
}

あとは得られたレスポンスをスプレッドシートへ保存する部分を追加する等、運用に沿った修正をしていくことになる。さらにその追加部分も生成AIに作ってもらえば、短時間に開発できる。

プログラミングスキルの必要性

　生成AIを利用することで非プログラマでも開発は以前に比べればかなり容易になっている。とはいえ、全く知らないことは生成AIに聞くこともできないので、何らかの形で処理の方針を立てることができるまでの知識やプログラミングスキルは必要になるし、例えばAppSuiteAPIの仕様の内容が知識のバックボーンが無く読めないなら、どこでエラーが出ているかもわからないだろう。
　コロナ期に流行ったRPAだが、結局のところ何らかの形でプログラミングに関する素養が無ければ、開発を進めていくのは困難であり定着しなかった組織も山のようにあるだろう。弊社も自分以外のメンバーの利用が芳しくなく導入の初期段階で断念した。
　そもそもAppSuiteで自動計算部品や自動処理、さらには他アプリケーションとの関係の追加及びデータ参照等を使いこなすことも難しい組織が多いのではないかとも思っているので、APIの利用の前にAppSuiteで提供されている標準的な機能でいかに効率化できるか、そして限界が来たときにはじめてAPIの利用を考えてほしい。


いいなと思ったら応援しよう！